數據庫：
1）取大批量數據時儘量不要使用ORDER BY，先取到內存再自行排序速度可以快許多倍。
2）緩解數據庫壓力的方法：
分表：比如按用戶ID每5W分一個表，此時將比一張500W的大表性能高許多倍
分庫：比如分爲讀寫、只讀、備份數據庫，在符合業務需求的前提下選擇數據庫的優先級爲 備份 > 只讀 > 讀寫
linux:
1）不同發行版的linux許多時候對程序是不兼容的，比如ubuntu與CentOS，在前者平臺上編譯好的代碼到後者上運行時偶爾會出現庫不兼容的情況；另，用於第三方LIB時要注意32位與64位的區別，許多時候需要重新在目標平臺編譯一份纔可以。
2）itoa函數並非在所有版本的linux都有，爲了確保write once & run anywhere，應儘量考慮使用sprintf來代替itoa。
3）查看進程路徑的方法：先ps aux | grep 找到進程ID，如8791，然後cd /proc/8791; ls -l | grep cwd，顯示的即是全路徑名，如cwd -> /usr/magic/php/bin
4）命令重定向的符號是`而不是'，即鍵盤左上角和~在一起那個而非單引號，比如kill -9 `cat x_serv.pid`，糾結ing~
5）rz傳輸文件加上-be可以有效避免傳輸大文件或二進制文件時的中斷或傳輸錯誤
c++:
1）基類的析構函數爲了安全起見一定要聲明爲虛函數，即使派生類使用默認的析構函數，否則當派生類對象被基類指針析構時會內存泄露！千萬不要感覺派生類中沒有需要手動釋放的成員變量就掉以輕心。
2）形如std::map<int, std::set<int>>之類的嵌套容器在VC2005下clear較慢，改爲std::map<int, std::set<int> *>可縮短時間到1/4。
3）使用vector時切忌有過多的erase操作，可以new一個vector，將希望保留的元素添加到新vector，之後釋放掉原vector，並使用新vector，兩者的效率差爲O(N^2)，N爲元素數，在典型的百W元素級時大約爲半分鐘VS10小時
4）模板函數中使用到的函數一定也要有模板版本，如果邏輯上確定只有某種類型會用到此函數，可只提供此類型的特化版本，泛型版本可以爲空，否則無法編譯通過。
5）對嵌套依賴類型名(nested dependent type name)前面需要加typename關鍵字來顯示地告訴編譯器，否則示編譯器不同有可能造成類型不被識別。
6）混合使用STL與BOOST庫時有時會出現莫名其妙的一堆編譯錯誤，此時可以嘗試調換包含頭文件的順序。
7）函數名與變量名相同時，對此函數遞歸調用會編譯出錯。
misc:
1）當一段新添加的邏輯未能得到預期結果時，首先是在各關鍵分支添加打印，確定一個或幾個出錯的函數，然後對這些函數分別作單元測試，盲目地反覆推敲代碼只是浪費時間。我的習慣是把出錯的函數添加到一個空的VS工程中，畢竟VS的調試功能比GDB方便太多，然後產生儘可能接近實際情況的模擬數據進行測試。
我的一段噪聲過濾代碼無效，調試發現n_max_artist_count一直爲0，然後發現：
if (n_cur_count > n_max_artist_count)
n_cur_count = n_max_artist_count;
fuck!
2）做底層庫時有些是應該幫上層做的，比如提供支持各種容器和指針的接口，但有些是應該留給上層來做的，比如
一個bool set_list(std::string &key, const void *p_begin, const void *p_end)看似某些時候可以省略掉上層的一步強制類型轉換，但對比
bool set_list(std::string &key, const T *p_begin, const T *p_end)
後者可以讓使用者在做強制類型轉換時意識到自己的行爲，而前者則自作聰明地把這一切給隱瞞在自己內部，增加了使用者的潛在風險。