舊陌桑
你好，我是全棧技術棧，很高興回答你的問題
可以從以下幾個方面對mysql進行優化：
1.對於select * 要時刻保持謹慎的態度
絕大多數情況，是不需要select *的。select * 為全表查詢，建議查詢指定的列信息
2.count()函數優化
count(列名)是不統計值為NULL的字段的！如果想要統計結果集，就使用count(*)，性能也會很好。
3.合理創建索引
並不是表的索引創建的越多越好
4.儘量不使用子查詢
子查詢在數據量大的情況下，性能會很低
5.儘量使用exist/not exist代替 in/not in
6.能避免使用join的避免使用，越簡單的sql一般效率是最高的
希望我的回答能夠幫到你，謝謝！
全棧技術棧
答： 本文邀請ryangz分享近來項目的mysql優化經驗~
準備知識
瞭解select的執行順序有助於理解語句的結果並對其進行優化，執行順序如下：
可以通過show status like 'XXX', show global status like 'XXX'，show variables like 'XXX' 查看很多重要的數據，eg：Connections 連接數，Slow_queries 慢查詢（可以用 show variables like ‘%slow%’來查詢是否開啟慢查詢日誌）等等。
可以通過 desc sql命令 （同樣可是使用explain命令，用法相同）獲取這個查詢的各種屬性，檢查這個語句是否達到性能標準。著重看重點要看這幾列：
rows（影響行數）
select_type（查詢類型，是單表查詢還是多表查詢）
type、possible_key和key（可能用到的索引，以及真正用到索引等）
[ possible_key說明可能用到索引competition_id，但是key為null表明最終沒有使用索引，進行了全表掃描，rows為全表數量 ]
[ 本次查詢是嵌套查詢，兩張表的主鍵都是id，通過desc命令可以看出，player_unique_id的查詢時使用的主鍵索引，影響條數rows為1，但是外部查詢雖然id是主鍵但是沒有使用索引，進行了全表查詢 ]
一些小技巧和注意事項：
（1）有些時候即便你加了索引，數據庫查詢的時候也不會使用：
like的%如果只有一個，並且放在開頭，則不會使用索引；eg ‘%user’不會使用索引，但是’user%’,’%user%’都會使用索引；
查詢的時候and和or 如果想使用索引的話需要前後都加索引，如果只有一個則不會使用索引；
如果查詢的時候該列是varchar，但是寫的時候沒有帶引號（寫成2018，而不是’2018’）,則不會使用索引；
反向條件查詢不能使用索引，儘量少用 !=,not in,not exists；
複合索引最左前綴，eg: 複合索引(name`, age)：
select * from XXX where age=? and name=? 使用索引
select * from XXX where name=? 使用索引
select from XXX where age=? *不使用索引
（2）儘量避免用嵌套查詢，外層的就算是主鍵也不會使用索引（可以參看準備知識中的例子），可以使用左連接、右連接或者相同的功能的其他寫法代替。
（3）如果明確知道只有一條結果返回，limit 1能夠提高效率
（4）所有不清楚的操作可以通過?查詢，類似linux的man操作，? view 就可以查詢視圖基本語法
（5）開始數據庫慢日誌：
vim /etc/my.cnf 添加log_slow_queries=slow.log 以及long_query_time=5(設置慢日誌的時長)， 然後重啟mysql
綜上，一般的查詢優化步驟如下：
（1）查看慢查詢日誌，或者通過show status命令查看數據庫各項指標是否正常，其中 show status like ‘%handler_read%’ 中 Handler_read_rnd_next如果很高的話，說明需要檢查索引了，看看是索引加的不對還是用法不對。
（2）找到問題的語句，通過desc定位這個語句到底哪裡有問題，是語句寫法問題、索引問題、還是表結構問題等等。
（3）優化語句，重複第1步，直到符合業務需求
騰訊技術工程
對數據庫優化我認為可以分一下步驟進行：\r
1、表結構優化；\r
根據實際項目的業務邏輯，對錶結構進行合理拆分，和合並；減少數據冗餘；適度的反範式。\r
對錶字段選擇適當的字段類型；\r
2、sql語句優化；\r
針對一下特定的SQL查詢進行優化，可以開啟mysql慢日誌，鎖定慢查詢語句然後進行查詢優化；具體的優化方案還得根據實際業務來定；比如select * 替換 具體的查詢字段；OR改寫為IN()查詢；查分join查詢等等；\r
3、合理構建索引，優化索引，避免濫用；\r
建立索引被多少人認為是提升數據庫性能的審計，於是甚至有人說把where後面所有的查詢字段都加上索引；需要搞清楚的是，索引的確可以大大提高查詢效率，但是索引對應添加和更新數據，增加了大量的I/O，而且對錶的存在空間增大；不合理的索引反而成了累贅。\r
4、構建集群；\r
搭建數據庫集群，配合數據庫中間件實現讀寫分離負載均衡；\r
5、存儲業務拆分；\r
對於一些業務和數據通過其他方式存在進行優化，比如檢索字段可以用ES或者Solr進行查分。
有點IT
1、對SQL語句、索引、表結構等進行優化。
2、開啟查詢緩存，Query Cache緩存了SELECT查詢及其結果數據集，當執行一個同樣的SELECT查詢時，MySQL會從內存中直接取出結果，加快了查詢執行速度、減小了數據庫的壓力。執行SHOW VARIABLES LIKE 'have_query_cache';可以查看MySQL查詢緩存是否打開，開啟查詢緩存只需配置my.cnf文件即可，具體如下：
query_cache_type = 1
query_cache_size = 128M
query_cache_limit = 1M
保存好後重啟MySQL。
3、選用InnoDB存儲引擎，MySQL常用存儲引擎是MyISAM和InnoDB，二者區別如下：
MyISAM
查詢速度快；
支持表級鎖，在上鎖期間表上不能進行其他操作；
支持全文檢索；
支持數據壓縮、自我複製、查詢緩存、數據加密；
不支持外鍵；
不支持事務，所以也就沒有COMMIT和ROLLBACK操作；
不支持集群數據庫。
InnoDB
支持行級鎖；
支持外鍵，對外鍵約束強制；
支持事務，可執行COMMIT和ROLLBACK操作；
支持數據壓縮、自我複製、查詢緩存、數據加密；
可用在集群環境，但並不完全支持。InnoDB表可以轉換為NDB存儲引擎，這樣就能用在集群環境。
大數據技術和人工智能
MySQL的優化要根據實際業務，並沒有什麼通用的優化。
其實其他回答都說的很全，
但是我從比較實際的地方說說吧。
第一、開啟MySQL的slowLog
slowLog會記錄MySQL執行過的慢查詢，比較佛系的辦法就是讓它記錄一段時間，
然後查看裡面執行的語句。
第二、通過desc的方式來查看慢的原因
比如：SELECT * FROM tbl WHERE Date = CURDATE();
你可以通過執行 desc SELECT * FROM tbl WHERE Date = CURDATE();
這個時候Mysql就會顯示執行這句sql的計劃，
如果你發現是全表查詢，這個時候嘗試在Date上增加索引，
然後再跑一次DESC，這個時候你就會發現這句語句已經走了索引。
*通常這個辦法能解決90%的慢查詢問題。
當上面的問題都無法滿足到你的時候，
建議可以參考Mysql官方的參數設定，
然後根據業務特性對MySQL進行特定優化。
賣女孩的小男孩M
首先，mysql優化並不是一個單純的優化，可能涉及到系統調整，mysql參數調整。mysql集群架構的調整，schema,表，字段的調整。因此，我們在談優化的時候，其實是一個綜合的問題。
建議：
1.對系統有一定的瞭解，比如磁盤IO，內存算法，CPU numa問題，TCP/IP原理等。
2.對mysql的原理，基本的參數，引擎，表，字段比較精通。
3.要對schema的設計，表設計，字段設計有足夠的瞭解和認知度。
4.對mysql索引，主鍵，外鍵，組合索引，前綴原則等了然於心。
5.SQL的優化，要讓mysql幹它擅長的事：數據存取，而不是複雜邏輯計算。這裡面內容非常多，技巧也特別多，除了看資料，還需要動手測試。
6.有些時候，不是僅僅對SQL優化，就能解決問題的，可能涉及到緩存，例如：分佈式緩存redis等。
7.對於JSON類型數據，你要了解mysql如何高效使用，也可能會使用mongodb，也需要了解。它的應用場景。
8.也行上面都做了，還是無法解決一些問題的時候，可能就要涉及到mysql架構的調整。常見的mysql架構，以及相關技術，要清楚。
如果需要視頻教程，或是推薦的書籍，可以私信我。
碼農上線
1.schema設計和數據類型優化
2.數據表索引優化
3.應用層緩存優化
4.sql語句優化等
