個人總結：
1）如果單表容量大（大於2G），但是索引少（只通過主鍵ID查），性能也不會慢
2）如果數據量大（大於500W），但是索引容量小（都是小字節字段），性能也不會慢
3）所以，單表查詢的性能取決於索引的大小（因爲會放內存裏），而索引的查詢速度又受硬件的影響。
4）建議：大表（數據量大、容量大）。先拆成主表（字段多）、detail表（容量高）。主表嚴格控制索引的質量，detail表只能用主鍵ID查（後期可以通過主鍵ID分表）。
以下是正文：
今天，探討一個有趣的話題：MySQL 單表數據達到多少時才需要考慮分庫分表？有人說 2000 萬行，也有人說 500 萬行。那麼，你覺得這個數值多少才合適呢？
曾經在中國互聯網技術圈廣爲流傳着這麼一個說法：MySQL 單表數據量大於 2000 萬行，性能會明顯下降。事實上，這個傳聞據說最早起源於百度。具體情況大概是這樣的，當年的 DBA 測試 MySQL性能時發現，當單表的量在 2000 萬行量級的時候，SQL 操作的性能急劇下降，因此，結論由此而來。然後又據說百度的工程師流動到業界的其它公司，也帶去了這個信息，所以，就在業界流傳開這麼一個說法。
再後來，阿里巴巴《Java 開發手冊》提出單錶行數超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。對此，有阿里的黃金鐵律支撐，所以，很多人設計大數據存儲時，多會以此爲標準，進行分表操作。
那麼，你覺得這個數值多少才合適呢？爲什麼不是 300 萬行，或者是 800 萬行，而是 500 萬行？也許你會說這個可能就是阿里的最佳實戰的數值吧？那麼，問題又來了，這個數值是如何評估出來的呢？稍等片刻，請你小小思考一會兒。
事實上，這個數值和實際記錄的條數無關，而與 MySQL 的配置以及機器的硬件有關。因爲，MySQL 爲了提高性能，會將表的索引裝載到內存中。InnoDB buffer size 足夠的情況下，其能完成全加載進內存，查詢不會有問題。但是，當單表數據庫到達某個量級的上限時，導致內存無法存儲其索引，使得之後的 SQL 查詢會產生磁盤 IO，從而導致性能下降。當然，這個還有具體的表結構的設計有關，最終導致的問題都是內存限制。這裏，增加硬件配置，可能會帶來立竿見影的性能提升哈。
那麼，我對於分庫分表的觀點是，需要結合實際需求，不宜過度設計，在項目一開始不採用分庫與分表設計，而是隨着業務的增長，在無法繼續優化的情況下，再考慮分庫與分表提高系統的性能。對此，阿里巴巴《Java 開發手冊》補充到：如果預計三年後的數據量根本達不到這個級別，請不要在創建表時就分庫分表。那麼，回到一開始的問題，你覺得這個數值多少才合適呢？我的建議是，根據自身的機器的情況綜合評估，如果心裏沒有標準，那麼暫時以 500 萬行作爲一個統一的標準，相對而言算是一個比較折中的數值。
我們再來看一下關於SQL書寫的一些注意點，會給大家帶來幫助
sql的編寫需要注意優化
使用limit對查詢結果的記錄進行限定
避免select *，將需要查找的字段列出來
使用連接（join）來代替子查詢
拆分大的delete或insert語句
可通過開啓慢查詢日誌來找出較慢的SQL
不做列運算：SELECT id WHERE age + 1 = 10，任何對列的操作都將導致表掃描，它包括數據庫教程函數、計算表達式等等，查詢時要儘可能將操作移至等號右邊
sql語句儘可能簡單：一條sql只能在一個cpu運算；大語句拆小語句，減少鎖時間；一條大sql可以堵死整個庫
OR改寫成IN：OR的效率是n級別，IN的效率是log(n)級別，in的個數建議控制在200以內
不用函數和觸發器，在應用程序實現
避免%xxx式查詢
少用JOIN
使用同類型進行比較，比如用'123'和'123'比，123和123比
儘量避免在WHERE子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描
對於連續數值，使用BETWEEN不用IN：SELECT id FROM t WHERE num BETWEEN 1 AND 5
列表數據不要拿全表，要使用LIMIT來分頁，每頁數量也不要太大