1、背景
innodb引擎儲存int型別時使用big-endian, 而mysql使用litter-endian, 導致乙個問題是在兩個層之間拷貝int型別資料的時候必須用乙個迴圈來處理，而不能直接memcpy。 在引擎層返回資料量很大的情況下，很耗cpu。
在報表類的一些查詢中，會訪問大量的資料。我們有個專案的乙個查詢需要訪問到1.4w個bigint，這個時候cpu的消耗就體現出來了。
2、相關**
目前使用的轉換**就是使用迴圈。
row_sel_field_store_in_mysql_format這個函式的作用是把資料從innodb格式轉成mysql格式，
如下：ptr = dest + len;
for (;;) {
ptr--;
*ptr = *data;
if (ptr == dest) {
break;
data++;
這裡如果是bigint就需要迴圈8次。
反過來的轉換**在row_mysql_store_col_in_innobase_format，也是類似的需要乙個迴圈。
3、改進和效果
這一坨迴圈，o3編譯以後的彙編**下，如果是bigint，需要40條指令。而顯然我們使用的時候，int和bigint會很多。
因此考慮當len=4或8的時候，使用bswap和bswapq實現。
修改後再用oprofile觀察上面說到的乙個統計查詢壓力下的結果，發現row_sel_field_store_in_mysql_format這個函式cpu佔用率從50%下降到44%.
db的多數情況下壓力還是在io，因此這個改進的效果需要在特定場景下才能體現。 最近跟oracle innodb工程師討論的時候了解到會有一些專門針對減少彙編結果做的優化，就湊熱鬧把這個提了。
patch內容： 基於5.5.22
小和問題和逆序對問題
在乙個陣列中，每乙個數左邊比當前數小的數累加起來，叫做這個陣列的小和。求乙個陣列的小和。例如 對於陣列 1,3,4,2,5 1左邊比1小的數，沒有 3左邊比3小的數，1 4左邊比4小的數，1 3 2左邊比2小的數，1 5左邊比5小的數，1 3 4 2 所以小和為1 1 3 1 1 3 4 2 16 ...
NP問題和NPC問題
什麼叫做np問題，什麼叫做npc問題?首先說明一下問題的複雜性和演算法的複雜性的區別，下面只考慮時間複雜性。演算法的複雜性是指解決問題的乙個具體的演算法的執行時 間，這是演算法的性質 問題的複雜性是指這個問題本身的複雜程度，是問題的性質。比如對於排序問題，如果我們只能通過元素間的相互比較 來確定元素...
相鄰問題和區域問題
相鄰問題使用 法解決 問題1 26個英文本母能組成多少4位數的字串，其中每位字母都不相同且b和d不相鄰？答案 num a 26,4 c 24,2 3 2 解析 先取總的方案數既 a 26,4 再將b d 看成乙個元素，相當於已經先取了b和d，再從26 2個元素中取2個出來，再對這3個元素進行全排列既...