優化sql索引；
第二，增加緩存，memcached，redis
第三，主從複制或者主主複制，讀寫分離。
第四，mysql自帶的分區表
第五垂直拆分
第六水準拆分，針對資料量大的表，選擇一個合理的sharding key。
在大量讀的應用場景下，mysql 的引擎應該用myisam。因為這個引擎的讀效果好，寫的效率比較差。這和它資料存儲格式，索引的指針和鎖的政策有關的，它的資料是順序存儲的（innodb資料存儲方式是聚簇索引），他的索引btree上的節點是一個指向資料實體位置的指針，是以查找起來很快，（innodb索引節點存的則是資料的主鍵，是以需要根據主鍵二次查找）；myisam鎖是表鎖，隻有讀讀之間是并發的，寫寫之間和讀寫之間（讀和插入之間是可以并發的，去設定concurrent_insert參數，定期執行表優化操作，更新操作就沒有辦法了）是串行的，是以寫起來慢，并且預設的寫優先級比讀優先級高，高到寫操作來了後，可以馬上插入到讀操作前面去，如果批量寫，會導緻讀請求餓死，是以要設定讀寫優先級或設定多少寫操作後執行讀操作的政策;myisam不要使用查詢時間太長的sql，如果政策使用不當，也會導緻寫餓死，是以盡量去拆分查詢效率低的sql,
innodb一般都是行鎖，這個一般指的是sql用到索引的時候，行鎖是加在索引上的，不是加在資料記錄上的，如果sql沒有用到索引，仍然會鎖定表,mysql的讀寫之間是可以并發的，普通的select是不需要鎖的，當查詢的記錄遇到鎖時，用的是一緻性的非鎖定快照讀，也就是根據資料庫隔離級别政策，會去讀被鎖定行的快照，其它更新或加鎖讀語句用的是目前讀，讀取原始行；因為普通讀與寫不沖突，是以innodb不會出現讀寫餓死的情況，又因為在使用索引的時候用的是行鎖，鎖的粒度小，競争相同鎖的情況就少，就增加了并發處理，是以并發讀寫的效率還是很優秀的，問題在于索引查詢後的根據主鍵的二次查找導緻效率低；