sql常用優化

mysql服務器優化

在sql優化前，瞭解mysql的基礎參數，然後有針對性的調優是很有必要的：

max_connections

mysql的最大連接數， 我們偶爾會遇到Too mant connetcions錯誤，這說明當前並行連接超過設置值

max_connections值的大小取決於：

• 給定平臺上線程庫的質量
• 可用的RAM量
• 每個連接使用的RAM
• 每個連接的工作負載
• 所需的響應時間
• 可用文件描述符的數量
  增大該 max_connections值會增加mysqld所需的文件描述符的數量 。如果所需數目的描述符不可用，則服務器將減少max_connections的值。
  max_connections過大會造成mysql初始化內存變大，因爲max_connections會爲每個連接提供RAM，過大的max_connections就會造成大量的物理機內存開銷，讓服務器宕機也是有可能的事。因此合理分配max_connections也是項目非常重要的一環。
  合理分配方式：
  max_connections產生內存 = 最大連接數* 每個連接使用的RAM
  在服務器可用內存，能夠負擔的情況下:
  show status like ‘max_used_connections’響應的連接數
  查看max_used_connections，
  max_used_connections / max_connections * 100% （理想值≈ 85%）
  如果max_used_connections跟max_connections相同 那麼就是max_connections設置過低或者超過服務器負載上限了，低於10%則設置過大。

back_log

MySQL可以擁有的未完成連接請求數。當主要的MySQL線程在很短的時間內收到很多連接請求超過max_connections，這就會起作用。該 back_log值指示在MySQL暫時停止回答新請求之前的短時間內可以堆疊多少個請求。僅當您期望在短時間內有大量連接時，才需要增加此數量。
默認值基於以下公式，上限爲900：
50 + (max_connections / 5)

innodb_buffer_pool_size

配置InnoDB緩衝池大小，當增加或減少時 innodb_buffer_pool_size，將按塊執行操作。塊大小由innodb_buffer_pool_chunk_size 配置選項定義 ，其默認值爲 128M。緩衝池大小必須始終等於innodb_buffer_pool_chunk_size的倍數，如果不爲倍數，緩衝池大小將自動調整爲等於innodb_buffer_pool_chunk_size的倍數。

• 判斷緩衝池是否過大
  show engine innodb status\G
  
  Free buffers :表示有多少空閒buffer。如果 此值長時間都較高，則可以考慮減小InnoDB緩衝池大小。

• 配置的innodb_buffer_pool_size是否合適？
  show status like ‘innodb_buffer_pool_read%’;
  

Performance = innodb_buffer_pool_reads / innodb_buffer_pool_read_requests * 100

innodb_buffer_pool_reads：表示InnoDB緩衝池無法滿足的請求數。需要從磁盤中讀取。

innodb_buffer_pool_read_requests：表示從內存中讀取邏輯的請求數。

0.0002797533222203554意味着InnoDB可以滿足緩衝池本身的大部分請求。從磁盤完成讀取的百分比非常小。因此無需增加innodb_buffer_pool_size值。

thread_cache_size

服務器應緩存多少線程以供重用。當客戶端斷開連接時，如果那裏的thread_cache_size線程少於該線程，則將客戶端的線程放入緩存中 。通過儘可能地重用從緩存中獲取的線程來滿足線程請求，並且僅當緩存爲空時才創建新線程。如果您有很多新連接，則可以增加此變量以提高性能。通常，如果您具有良好的線程實現，則這不會顯着提高性能。但是，如果您的服務器每秒看到數百個連接，則通常應設置 thread_cache_size足夠高，以便大多數新連接使用緩存的線程。
默認值基於以下公式，上限爲100：
8 + (max_connections / 100)

mysql數據庫結構優化

優化數值數據

1. 對於可以表示爲字符串或數字的唯一ID或其他值，與字符串列相比，首選數字列。由於大數值可以比相應字符串存儲在更少的字節中，因此傳輸速度更快，並且佔用更少的內存來進行比較。

2. 如果您使用的是數字數據，則在許多情況下（通過實時連接）從數據庫訪問信息的訪問要比訪問文本文件更快。數據庫中的信息很可能以比文本文件更緊湊的格式存儲，因此訪問它涉及的磁盤訪問較少。

優化字段類型

數據的檢索效率： char > varchar > text
1、經常變化的字段用varchar；
2、知道固定長度的用char；
3、超過255字節的只能用varchar或者text；
4、能用varchar的地方不用text；
5、能夠用數字類型的字段儘量選擇數字類型而不用字符串類型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因爲引擎在處理查詢和連接回逐個比較字符串中每一個字符，而對於數字型而言只需要比較一次就夠了；
6、同一張表出現多個大字段，能合併時儘量合併，不能合併時考慮分表

業務邏輯優化

分表

隨着時間和業務的發展，同一個表中的數據量不可避免的越來越大，相應地，數據操作，增刪改查的開銷也會越來越大。因此我們可以按照業務邏輯的劃分，將一個表拆分成多個表。例如商品表，我們可以根據商品類型拆分成：普通商品表、積分商品表、特價山商品表等等。

讀寫分離

在多臺服務器上部署mysql，將其中一個設置爲主數據庫，負責寫入操作，其他數據庫設置爲從數據庫，負責讀取操作。開啓slave實現數據庫同步，這樣可以極大的減輕數據庫的壓力。

sql語句優化

開啓慢查詢

要實現對sql語句性能實時的監控，首先要開啓慢查詢。
查看慢查詢是否開啓
show variables like ‘slow_query%’;

查看參數設置
show variables like ‘long_query_time’;

開啓慢查詢
set global slow_query_log=‘ON’;

設置慢查詢時間：
set global long_query_time=1;
超過一秒就記錄下來

檢查explain

當我們記錄下來這些查詢比較慢的sql，就可以有針對性的去優化了。首先執行sql，點擊解析按鈕，查看type列。
當語句的type爲all時說明是全表掃描，這個時候我們就可以有針對性的對sql進行優化、例如加索引、避免使用讓索引失效的從而引發全表掃描的命令

參考文檔：
1.https://www.cnblogs.com/wanbin/p/9530833.html