最近在做一套mysql環境的資料遷移，需要把一部分資料從乙個站點遷移到另外乙個站點，新站點是一套全新的環境，對於mysql的安裝採用了同事建議的二進位制方式。當然安裝的過程比起oracle的安裝看起來要簡單很多了。基本做到了一鍵安裝的程度。因為對於mysql還是有很多的盲點，所以感覺還是有些心虛，當然態度是虛心的了。可能很多問題處理起來就不會像oracle那樣理直氣壯了。這可能也是好事。
資料庫安裝很快就做好了，而且裡面的很多引數也採用了一定的規則去匹配一些引數值，所以自己也沒做其它的改變就直接使用了。使用mysqldump從源站點匯出資料在目標站點匯入。看起來倒也是蠻順利的。接著按照源站點的使用者ip和目標站點的使用者ip進行了對映，看似大功告成。然後對相應的客戶端開通了防火牆許可權，簡單本地測試連線了一下都沒問題，就讓開發的同事來進行聯調了。
但是過了一會兒，他們反饋說連線有問題，自己還是有些心虛，感覺是不是**還是有問題，
他們反饋的問題是使用telnet連線埠3308不通。
比如埠是telnet 10.172.13.23 3308
trying 10.172.13.23...
telnet: connect to address 10.172.13.23: connection refused
對於這個問題，自己也是再三檢視了防火牆的設定，沒有發現問題。自己也連線到他們所在的客戶端去看，發現問題確實存在，但是開了ssh的22埠是沒有問題的。
檢視資料庫中的埠引數，發現竟然是0
> show variables like '%port%';
+---------------------+-------+
| variable_name | value |
+---------------------+-------+
| extra_port | 0 |
| innodb_support_xa | on |
| large_files_support | on |
| port | 0 |
| report_host | |
| report_password | |
| report_port | 0 |
| report_user | |
+---------------------+-------+
8 rows in set (0.00 sec)
檢視了一下引數檔案的設定
#grep port /etc/my.cnf
port = 3308
埠也沒有發現問題。檢視資料庫的日誌，發現了下面這麼一段內容。
2015-11-27 18:28:32 9364 [note] event scheduler: loaded 0 events
2015-11-27 18:28:32 9364 [note] /usr/local/mysql/bin/mysqld: ready for connections.
version: '5.6.23-72.1' socket: '/home/mysql/mysql.sock' port: 0 percona server (gpl), release 72.1, revision 0503478
從日誌來看也沒有提示警告或者錯誤。
於是帶著疑問去問幾個同事，他們可能認為這個問題不是乙個簡單的問題，我們也分析了一下引數檔案的設定格式，埠，防火牆的限制等等。
我們也在懷疑是不是網路層做了什麼限制，導致3308的埠無法啟用，然後找到系統組的同事幫忙看看，他們直接用了nc的方式開啟乙個3308的埠，然後使用telnet連線就成功了，看來不是系統中網路層設定的限制，那麼問題又回到了資料庫層面。
但是做了多次嘗試，還是無果，最後感覺是不是提供的經典模板不靠譜啊。於是從原來的環境中拷貝了乙份引數檔案，除了個別引數不相容外，做了修改，總算是把庫給帶起來了，檢視埠，這次終於對了，是3308.
但是兩個引數檔案的引數其實設定也還是蠻多的，自己最開始也就想跳過就算了。不過感覺這種問題處理，這次僥倖通過了，下次還是會出現。沒找到根本，自己感覺也不踏實。
同事也建議我做乙個strace來看看。
strace /usr/local/mysql/bin/mysqld —defaults-file=/etc/my.cnf &
但是從trace的情況來看，還是沒有找到更多的有效資訊。
在大晚上開始準備試一試，準備好兩個引數檔案，準備sdiff一下來看看。比較的結果如下，左邊的是沒有問題的，埠正常開放的，右邊的是存在連線問題的。
character-set-server = utf8 character-set-server = utf8
#performance #performance
net_read_timeout = 60 net_read_timeout = 60
open_files_limit = 65535 open_files_limit = 65535
back_log = 150 back_log = 150
max_connections = 500 | max_connections = 350
max_connect_errors = 100000 max_connect_errors = 100000
external-locking = false external-locking = false
binlog_cache_size = 4m binlog_cache_size = 4m
performance_schema = 1 performance_schema = 1
timed_mutexes = 1 timed_mutexes = 1
#locked_in_memory = 1 #locked_in_memory = 1
#max_binlog_cache_size = 2g | thread_handling=pool-of-threads
#skip-networking | extra_port=3300
> extra_max_connections = 1
> thread_pool_max_threads = 300
這是一部分的引數對比情況，自己也是對比了一部分，但是從個別幾個引數調整來重啟測試，還是沒有找到答案。
今天在和同事聊天的過程中，經同事提醒才發現原來是skip-networking導致的，這個引數啟用，則意味著沒有了網路訪問，只有本機的訪問連線，一種用法其實在做維護的時候，為了防止更多的客戶端連線進來，就可以採用這種方式。看來自己繞了乙個大圈子，最後竟然原因是乙個看似簡單的引數導致。簡答調整之後，問題就自然修復了。
所謂吃一塹長一智，這種錯誤以後碰到就會更加從容。看來mysql的引數也需要好好琢磨琢磨了，還有一大堆的坑等著我去踩：）
VLOOKUP函式最後乙個引數導致的問題
今天同事問了我乙個vlookup函式的問題。他在使用這個函式時發現明明有值卻顯示 n a。公式是複製的，只有一行沒有結果，其它都有結果，不存在公式錯誤或者值不對的問題，如下圖所示 我們知道，vlookup第4引數 最後乙個引數 為true或忽略時是非精確匹配，為false或0時是精確匹配，如下圖 同...
close掉乙個失效的MySQL連線導致的程式崩潰
這在沒有鏈結池控制的應用中十分常見，而我正好在做和mysql相關的開發工作，在一般的工具類應用中，並沒有使用鏈結池進行連線的管理，而是直接使用mysql提供的c api進行操作。而這給我的程式帶來過很多麻煩 比如 如下 int main cout mysql ping conn endl mysql...
Calendar 導致的乙個bug
查詢不到資料。把calendar生成的date通過gettime 列印出時間戳。因為資料庫裡的資料是每天生成的，所以對應的時間毫秒為0，而calendar生成的時間沒有對毫秒進行set值覆蓋，導致使用到了當前時間的毫秒值。此時由於查詢條件是 導致這部分資料被忽略掉了。由於 calendar.geti...