scheme設計與資料型別優化
選擇資料型別只要遵循小而簡單的原則就好，越小的資料型別通常會更快，占用更少的磁碟、記憶體，處理時需要的cpu週期也更少。越簡單的資料型別在計算時需要更少的cpu週期，比如，整型就比字元操作代價低，因而會使用整型來儲存ip位址，使用datetime來儲存時間，而不是使用字串。
這裡總結幾個可能容易理解錯誤的技巧：
通常來說把可為null的列改為not null不會對效能提公升有多少幫助，只是如果計畫在列上建立索引，就應該將該列設定為not null。
對整數型別指定寬度，比如int(11)，沒有任何卵用。int使用32位（4個位元組）儲存空間，那麼它的表示範圍已經確定，所以int(1)和int(20)對於儲存和計算是相同的。
unsigned表示不允許負值，大致可以使正數的上限提高一倍。比如tinyint儲存範圍是-128 ~ 127，而unsigned tinyint儲存的範圍卻是0 - 255。
通常來講，沒有太大的必要使用decimal資料型別。即使是在需要儲存財務資料時，仍然可以使用bigint。比如需要精確到萬分之一，那麼可以將資料乘以一百萬然後使用bigint儲存。這樣可以避免浮點數計算不準確和decimal精確計算代價高的問題。
timestamp使用4個位元組儲存空間，datetime使用8個位元組儲存空間。因而，timestamp只能表示1970 - 2023年，比datetime表示的範圍小得多，而且timestamp的值因時區不同而不同。
大多數情況下沒有使用列舉型別的必要，其中乙個缺點是列舉的字串列表是固定的，新增和刪除字串（列舉選項）必須使用alter table（如果只只是在列表末尾追加元素，不需要重建表）。
schema的列不要太多。原因是儲存引擎的api工作時需要在伺服器層和儲存引擎層之間通過行緩衝格式拷貝資料，然後在伺服器層將緩衝內容解碼成各個列，這個轉換過程的代價是非常高的。如果列太多而實際使用的列又很少的話，有可能會導致cpu占用過高。
大表alter table非常耗時，mysql執行大部分修改表結果操作的方法是用新的結構建立乙個張空表，從舊表中查出所有的資料插入新錶，然後再刪除舊表。尤其當記憶體不足而表又很大，而且還有很大索引的情況下，耗時更久。當然有一些奇技淫巧可以解決這個問題，有興趣可自行查閱。
Mysql效能優化小建議
mysql的效能優化主要參考文章 1 2 和 3 其中已使用且比較有效果的有 1 禁止autocommit,防止每次插入都提交，重新整理log set autocommit 0 sql import statements commit 2 對頻繁查詢的字段建立索引，但要注意加入索引後，執行插入操作時...
MySQL效能優化的建議
為查詢快取優化你的查詢 explain 你的 select 查詢 當只要一行資料時使用 limit 1 為搜尋欄位建索引 在join表的時候使用相當型別的例，並將其索引 千萬不要 order by rand 避免 select 永遠為每張表設定乙個id 使用 enum 而不是 varchar 從 p...
mysql 效能優化的幾點建議
1 盡量取出自己想要的字段，不要這樣select from table 因為你取的越多，網路傳輸的資料就越多，從網路頻寬和網路緩衝區上來看都是浪費。特別是在order，效能更是下降。實現方式是先將需要排序的字段和可以直接定位到相關行資料的指標資訊取 出，然後在我們所設定的排序區 通過引數sort b...