我們考慮的情況是在你的資料量很大的情況下，千萬級別的資料量。不要當我們的請求響應時間已經讓我無法忍受的時候，再來想起來優化，可能有點遲了。因為可能會丟失很多潛在的價值客戶。所以，在我們當初設計表，或者因為我們的業務的變化而導致的情況下，就要多多考慮去優化我們的mysql了。
1、在我們的開發中，請務必注意我們的sql書寫，可能你的乙個sql導致全站掛掉了。所以要優化好我們的sql，這其中不得不說，索引。sql 的優化和索引 密不可分。優化sql 一部分是業務邏輯的優化，一部分就是索引的優化。至於怎麼優化，網上太多了。也可以看我其他文章有介紹。
2、當我們覺得上面的做的很不錯了，還是訪問慢，考慮下加快取把。這裡的快取可以是 a檔案快取 b mysql的buffer c nginx或者apace的快取設定 d客戶端瀏覽器的快取 e 更重要的是nosql型別的快取，增加memcache 和 redis。確實好，基於記憶體的讀寫自然比操作硬碟快把
3、我們的資料量還在增加，我們就考慮下mysql的讀寫分離了，進而涉及到主從複製等情況，不過這裡需要對sql 語句進行稍微改動下。要不怎麼知道讀哪台伺服器，寫哪台。
4、接下來，我們考慮我們的業務了，隨著併發量不斷增加，老闆這時候開心壞了。這都是錢啊。那就分表把。100萬條記錄的表，分5張 10張都行。不過前提需要按照一定的規則的，比方id為1的在member1表，2的在member表，一次類推；或者啊id在1-100的在1表，101-200的2表，以此類推。意思就是這樣的。不過需要我們在sql的時候，寫好讀哪個表，寫那個表的規則。其實也簡單。
5、區分熱表和冷表。也就是垂直切分表了。顧名思義，熱表代表經常更新的，操作比較頻繁的，冷表，則相反。
這其中我們需要考慮以下問題
表引擎的選擇。在幾年前預設就是mysiam，現在你再看看，預設是innodb型別的。
伺服器的配置情況。
MySQL大資料LIMIT優化
問題 專案每日遊戲日誌表資料量由原來1w 增長到千萬級別，原先獲取資料方式 select from table一次性取出的資料量太大導致記憶體溢位。既然一次性取資料不行，那就分次處理 1 1.使用limit每次取5w條資料 select from table limit 0,50000 select...
Mysql大資料量分頁優化
假設有乙個千萬量級的表，取1到10條資料 select from table limit 0,10 select from table limit 1000,10 這兩條語句查詢時間應該在毫秒級完成 select from table limit 3000000,10 你可能沒想到，這條語句執行之間...
MySQL效能優化大資料量插入資料
專案背景 對mysql資料進行初始化加密 假設待加密表 表名student，列名a，擁有5000w資料量 這個方案缺陷在於，修改列 刪除列會重建表，給所有資料行新增一段資料，所以會導致資料量越大越耗時。如果無法繞過新增列，那麼就得使用online ddl，最大限度減少鎖的使用。使用方式 alter ...