Mysql優化

2021-03-02 物聯網網際網路金融家居機械一體化
前言

BATJTMD等大廠的面試難度越來越高，但無論從大廠還是到小公司，一直未變的一個重點就是對SQL優化經驗的考察。一提到資料庫，先「說一說你對SQL優化的見解吧？」。

SQL優化已經成為衡量程序猿優秀與否的硬性指標，甚至在各大廠招聘崗位職能上都有明碼標註，如果是你，在這個問題上能吊打面試官還是會被吊打呢？

注:如果看著模糊，可能是你擼多了

目錄

前言

SELECT語句 - 語法順序：

SELECT語句 - 執行順序：

SQL優化策略

一、避免不走索引的場景

二、SELECT語句其他優化

三、增刪改 DML 語句優化

四、查詢條件優化

五、建表優化

有朋友疑問到，SQL優化真的有這麼重要麼？如下圖所示，SQL優化在提升系統性能中是：（成本最低 && 優化效果最明顯） 的途徑。如果你的團隊在SQL優化這方面搞得很優秀，對你們整個大型系統可用性方面無疑是一個質的跨越，真的能讓你們老闆省下不止幾沓子錢。

優化成本：硬體>系統配置>資料庫表結構>SQL及索引。

優化效果：硬體<系統配置<資料庫表結構<SQL及索引。

String result = "嗯，不錯，";
 
if ("SQL優化經驗足") {
    if ("熟悉事務鎖") {
        if ("並發場景處理666") {
            if ("會打王者榮耀") {
                result += "明天入職" 
            }
        }
    }
} else {
    result += "先回去等消息吧";
} 
 
Logger.info("面試官：" + result );
別看了，上面這是一道送命題。
好了我們言歸正傳，首先，對於MySQL層優化我一般遵從五個原則：
減少數據訪問：設置合理的欄位類型，啟用壓縮，通過索引訪問等減少磁碟IO
返回更少的數據：只返回需要的欄位和數據分頁處理 減少磁碟io及網絡io
減少交互次數：批量DML操作，函數存儲等減少數據連接次數
減少伺服器CPU開銷：儘量減少資料庫排序操作以及全表查詢，減少cpu 內存佔用
利用更多資源：使用表分區，可以增加並行操作，更大限度利用cpu資源
總結到SQL優化中，就三點:
理解SQL優化原理 ，首先要搞清楚SQL執行順序：
SELECT語句 - 語法順序：
1. SELECT 
2. DISTINCT <select_list>
3. FROM <left_table>
4. <join_type> JOIN <right_table>
5. ON <join_condition>
6. WHERE <where_condition>
7. GROUP BY <group_by_list>
8. HAVING <having_condition>
9. ORDER BY <order_by_condition>
10.LIMIT <limit_number>
SELECT語句 - 執行順序：
FROM
<表名> # 選取表，將多個表數據通過笛卡爾積變成一個表。
ON
<篩選條件> # 對笛卡爾積的虛表進行篩選
JOIN <join, left join, right join...> 
<join表> # 指定join，用於添加數據到on之後的虛表中，例如left join會將左表的剩餘數據添加到虛表中
WHERE
<where條件> # 對上述虛表進行篩選
GROUP BY
<分組條件> # 分組
<SUM()等聚合函數> # 用於having子句進行判斷，在書寫上這類聚合函數是寫在having判斷裡面的
HAVING
<分組篩選> # 對分組後的結果進行聚合篩選
SELECT
<返回數據列表> # 返回的單列必須在group by子句中，聚合函數除外
DISTINCT
# 數據除重
ORDER BY
<排序條件> # 排序
LIMIT
<行數限制>
SQL優化策略
聲明：以下SQL優化策略適用於數據量較大的場景下，如果數據量較小，沒必要以此為準，以免畫蛇添足。
一、避免不走索引的場景
1. 儘量避免在欄位開頭模糊查詢，會導致資料庫引擎放棄索引進行全表掃描。如下：
SELECT * FROM t WHERE username LIKE '%陳%'
優化方式：儘量在欄位後面使用模糊查詢。如下：
SELECT * FROM t WHERE username LIKE '陳%'
如果需求是要在前面使用模糊查詢，
使用MySQL內置函數INSTR(str,substr) 來匹配，作用類似於java中的indexOf()，查詢字符串出現的角標位置
使用FullText全文索引，用match against 檢索
數據量較大的情況，建議引用ElasticSearch、solr，億級數據量檢索速度秒級
當表數據量較少（幾千條兒那種），別整花裡胡哨的，直接用like '%xx%'。
2. 儘量避免使用in 和not in，會導致引擎走全表掃描。如下：
SELECT * FROM t WHERE id IN (2,3)
優化方式：如果是連續數值，可以用between代替。如下：
SELECT * FROM t WHERE id BETWEEN 2 AND 3
如果是子查詢，可以用exists代替。如下：
-- 不走索引
select * from A where A.id in (select id from B);
-- 走索引
select * from A where exists (select * from B where B.id = A.id);
3. 儘量避免使用 or，會導致資料庫引擎放棄索引進行全表掃描。如下：
SELECT * FROM t WHERE id = 1 OR id = 3
優化方式：可以用union代替or。如下：
SELECT * FROM t WHERE id = 1
   UNION
SELECT * FROM t WHERE id = 3
4. 儘量避免進行null值的判斷，會導致資料庫引擎放棄索引進行全表掃描。如下：
SELECT * FROM t WHERE score IS NULL
優化方式：可以給欄位添加默認值0，對0值進行判斷。如下：
SELECT * FROM t WHERE score = 0
5.儘量避免在where條件中等號的左側進行表達式、函數操作，會導致資料庫引擎放棄索引進行全表掃描。
可以將表達式、函數操作移動到等號右側。如下：
-- 全表掃描
SELECT * FROM T WHERE score/10 = 9
-- 走索引
SELECT * FROM T WHERE score = 10*9
6. 當數據量大時，避免使用where 1=1的條件。通常為了方便拼裝查詢條件，我們會默認使用該條件，資料庫引擎會放棄索引進行全表掃描。如下：
SELECT username, age, sex FROM T WHERE 1=1
優化方式：用代碼拼裝sql時進行判斷，沒 where 條件就去掉 where，有where條件就加 and。
搜索Java知音公眾號，回復「後端面試」，送你一份Java面試題寶典.pdf
7. 查詢條件不能用 <> 或者 !=
使用索引列作為條件進行查詢時，需要避免使用<>或者!=等判斷條件。如確實業務需要，使用到不等於符號，需要在重新評估索引建立，避免在此欄位上建立索引，改由查詢條件中其他索引欄位代替。
8. where條件僅包含複合索引非前置列
如下：複合（聯合）索引包含key_part1，key_part2，key_part3三列，但SQL語句沒有包含索引前置列"key_part1"，按照MySQL聯合索引的最左匹配原則，不會走聯合索引。
select col1 from table where key_part2=1 and key_part3=2
9. 隱式類型轉換造成不使用索引
如下SQL語句由於索引對列類型為varchar，但給定的值為數值，涉及隱式類型轉換，造成不能正確走索引。
select col1 from table where col_varchar=123;
10. order by 條件要與where中條件一致，否則order by不會利用索引進行排序
-- 不走age索引
SELECT * FROM t order by age;
 
-- 走age索引
SELECT * FROM t where age > 0 order by age;
對於上面的語句，資料庫的處理順序是：
第一步：根據where條件和統計信息生成執行計劃，得到數據。
第二步：將得到的數據排序。當執行處理數據（order by）時，資料庫會先查看第一步的執行計劃，看order by 的欄位是否在執行計劃中利用了索引。如果是，則可以利用索引順序而直接取得已經排好序的數據。如果不是，則重新進行排序操作。
當order by 中的欄位出現在where條件中時，才會利用索引而不再二次排序，更準確的說，order by 中的欄位在執行計劃中利用了索引時，不用排序操作。
這個結論不僅對order by有效，對其他需要排序的操作也有效。比如group by 、union 、distinct等。
11. 正確使用hint優化語句
MySQL中可以使用hint指定優化器在執行時選擇或忽略特定的索引。一般而言，處於版本變更帶來的表結構索引變化，更建議避免使用hint，而是通過Analyze table多收集統計信息。但在特定場合下，指定hint可以排除其他索引幹擾而指定更優的執行計劃。
USE INDEX 在你查詢語句中表名的後面，添加 USE INDEX 來提供希望 MySQL 去參考的索引列表，就可以讓 MySQL 不再考慮其他可用的索引。例子: SELECT col1 FROM table USE INDEX (mod_time, name)...
IGNORE INDEX 如果只是單純的想讓 MySQL 忽略一個或者多個索引，可以使用 IGNORE INDEX 作為 Hint。例子: SELECT col1 FROM table IGNORE INDEX (priority) ...
FORCE INDEX 為強制 MySQL 使用一個特定的索引，可在查詢中使用FORCE INDEX 作為Hint。例子: SELECT col1 FROM table FORCE INDEX (mod_time) ...
在查詢的時候，資料庫系統會自動分析查詢語句，並選擇一個最合適的索引。但是很多時候，資料庫系統的查詢優化器並不一定總是能使用最優索引。如果我們知道如何選擇索引，可以使用FORCE INDEX強制查詢使用指定的索引。
例如：
SELECT * FROM students FORCE INDEX (idx_class_id) WHERE class_id = 1 ORDER BY id DESC;
二、SELECT語句其他優化
1. 避免出現select *
首先，select * 操作在任何類型資料庫中都不是一個好的SQL編寫習慣。
使用select * 取出全部列，會讓優化器無法完成索引覆蓋掃描這類優化，會影響優化器對執行計劃的選擇，也會增加網絡帶寬消耗，更會帶來額外的I/O,內存和CPU消耗。
建議提出業務實際需要的列數，將指定列名以取代select *。
2. 避免出現不確定結果的函數
特定針對主從複製這類業務場景。由於原理上從庫複製的是主庫執行的語句，使用如now()、rand()、sysdate()、current_user()等不確定結果的函數很容易導致主庫與從庫相應的數據不一致。另外不確定值的函數,產生的SQL語句無法利用query cache。
3.多表關聯查詢時，小表在前，大表在後。
在MySQL中，執行 from 後的表關聯查詢是從左往右執行的（Oracle相反），第一張表會涉及到全表掃描，所以將小表放在前面，先掃小表，掃描快效率較高，在掃描後面的大表，或許只掃描大表的前100行就符合返回條件並return了。
例如：表1有50條數據，表2有30億條數據；如果全表掃描表2，你品，那就先去吃個飯再說吧是吧。
4. 使用表的別名
當在SQL語句中連接多個表時，請使用表的別名並把別名前綴於每個列名上。這樣就可以減少解析的時間並減少哪些友列名歧義引起的語法錯誤。
5. 用where字句替換HAVING字句
避免使用HAVING字句，因為HAVING只會在檢索出所有記錄之後才對結果集進行過濾，而where則是在聚合前刷選記錄，如果能通過where字句限制記錄的數目，那就能減少這方面的開銷。HAVING中的條件一般用於聚合函數的過濾，除此之外，應該將條件寫在where字句中。
where和having的區別：where後面不能使用組函數
6.調整Where字句中的連接順序
MySQL採用從左往右，自上而下的順序解析where子句。根據這個原理，應將過濾數據多的條件往前放，最快速度縮小結果集。
三、增刪改 DML 語句優化
1. 大批量插入數據
如果同時執行大量的插入，建議使用多個值的INSERT語句(方法二)。這比使用分開INSERT語句快（方法一），一般情況下批量插入效率有幾倍的差別。
方法一：
insert into T values(1,2); 
 
insert into T values(1,3); 
 
insert into T values(1,4);
方法二：
Insert into T values(1,2),(1,3),(1,4);
選擇後一種方法的原因有三。
減少SQL語句解析的操作，MySQL沒有類似Oracle的share pool，採用方法二，只需要解析一次就能進行數據的插入操作；
2. 適當使用commit
適當使用commit可以釋放事務佔用的資源而減少消耗，commit後能釋放的資源如下：
釋放事務施加的，減少鎖爭用影響性能。特別是在需要使用delete刪除大量數據的時候，必須分解刪除量並定期commit。
3. 避免重複查詢更新的數據
針對業務中經常出現的更新行同時又希望獲得改行信息的需求，MySQL並不支持PostgreSQL那樣的UPDATE RETURNING語法，在MySQL中可以通過變量實現。
例如，更新一行記錄的時間戳，同時希望查詢當前記錄中存放的時間戳是什麼，簡單方法實現：
Update t1 set time=now() where col1=1; 
 
Select time from t1 where id =1; 
使用變量，可以重寫為以下方式：
Update t1 set time=now () where col1=1 and @now: = now (); 
 
Select @now; 
前後二者都需要兩次網絡來回，但使用變量避免了再次訪問數據表，特別是當t1表數據量較大時，後者比前者快很多。
4.查詢優先還是更新（insert、update、delete）優先
MySQL 還允許改變語句調度的優先級，它可以使來自多個客戶端的查詢更好地協作，這樣單個客戶端就不會由於鎖定而等待很長時間。改變優先級還可以確保特定類型的查詢被處理得更快。我們首先應該確定應用的類型，判斷應用是以查詢為主還是以更新為主的，是確保查詢效率還是確保更新的效率，決定是查詢優先還是更新優先。
下面我們提到的改變調度策略的方法主要是針對只存在表鎖的存儲引擎，比如 MyISAM 、MEMROY、MERGE，對於Innodb 存儲引擎，語句的執行是由獲得行鎖的順序決定的。MySQL 的默認的調度策略可用總結如下：
1）寫入操作優先於讀取操作。
2）對某張數據表的寫入操作某一時刻只能發生一次，寫入請求按照它們到達的次序來處理。
3）對某張數據表的多個讀取操作可以同時地進行。MySQL 提供了幾個語句調節符，允許你修改它的調度策略：
LOW_PRIORITY關鍵字應用於DELETE、INSERT、LOAD DATA、REPLACE和UPDATE；
HIGH_PRIORITY關鍵字應用於SELECT和INSERT語句；
DELAYED關鍵字應用於INSERT和REPLACE語句。
如果寫入操作是一個 LOW_PRIORITY（低優先級）請求，那麼系統就不會認為它的優先級高於讀取操作。在這種情況下，如果寫入者在等待的時候，第二個讀取者到達了，那麼就允許第二個讀取者插到寫入者之前。只有在沒有其它的讀取者的時候，才允許寫入者開始操作。這種調度修改可能存在 LOW_PRIORITY寫入操作永遠被阻塞的情況。
SELECT 查詢的HIGH_PRIORITY（高優先級）關鍵字也類似。它允許SELECT 插入正在等待的寫入操作之前，即使在正常情況下寫入操作的優先級更高。另外一種影響是，高優先級的 SELECT 在正常的 SELECT 語句之前執行，因為這些語句會被寫入操作阻塞。如果希望所有支持LOW_PRIORITY 選項的語句都默認地按照低優先級來處理，那麼 請使用--low-priority-updates 選項來啟動伺服器。通過使用 INSERTHIGH_PRIORITY 來把 INSERT 語句提高到正常的寫入優先級，可以消除該選項對單個INSERT語句的影響。
搜索Java知音公眾號，回復「後端面試」，送你一份Java面試題寶典.pdf
四、查詢條件優化
1. 對於複雜的查詢，可以使用中間臨時表 暫存數據
2. 優化group by語句
默認情況下，MySQL 會對GROUP BY分組的所有值進行排序，如 「GROUP BY col1，col2，....;」 查詢的方法如同在查詢中指定 「ORDER BY col1，col2，...;」 如果顯式包括一個包含相同的列的 ORDER BY子句，MySQL 可以毫不減速地對它進行優化，儘管仍然進行排序。
因此，如果查詢包括 GROUP BY 但你並不想對分組的值進行排序，你可以指定 ORDER BY NULL禁止排序。例如：
SELECT col1, col2, COUNT(*) FROM table GROUP BY col1, col2 ORDER BY NULL ;
3. 優化join語句
MySQL中可以通過子查詢來使用 SELECT 語句來創建一個單列的查詢結果，然後把這個結果作為過濾條件用在另一個查詢中。使用子查詢可以一次性的完成很多邏輯上需要多個步驟才能完成的 SQL 操作，同時也可以避免事務或者表鎖死，並且寫起來也很容易。但是，有些情況下，子查詢可以被更有效率的連接(JOIN)..替代。
例子：假設要將所有沒有訂單記錄的用戶取出來，可以用下面這個查詢完成：
SELECT col1 FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
如果使用連接(JOIN).. 來完成這個查詢工作，速度將會有所提升。尤其是當 salesinfo表中對 CustomerID 建有索引的話，性能將會更好，查詢如下：
SELECT col1 FROM customerinfo 
   LEFT JOIN salesinfoON customerinfo.CustomerID=salesinfo.CustomerID 
      WHERE salesinfo.CustomerID IS NULL 
連接(JOIN).. 之所以更有效率一些，是因為 MySQL 不需要在內存中創建臨時表來完成這個邏輯上的需要兩個步驟的查詢工作。
4. 優化union查詢
MySQL通過創建並填充臨時表的方式來執行union查詢。除非確實要消除重複的行，否則建議使用union all。原因在於如果沒有all這個關鍵詞，MySQL會給臨時表加上distinct選項，這會導致對整個臨時表的數據做唯一性校驗，這樣做的消耗相當高。
高效：
SELECT COL1, COL2, COL3 FROM TABLE WHERE COL1 = 10 
 
UNION ALL 
 
SELECT COL1, COL2, COL3 FROM TABLE WHERE COL3= 'TEST'; 
低效：
SELECT COL1, COL2, COL3 FROM TABLE WHERE COL1 = 10 
 
UNION 
 
SELECT COL1, COL2, COL3 FROM TABLE WHERE COL3= 'TEST';
5.拆分複雜SQL為多個小SQL，避免大事務
簡單的SQL容易使用到MySQL的QUERY CACHE；
6. 使用truncate代替delete
當刪除全表中記錄時，使用delete語句的操作會被記錄到undo塊中，刪除記錄也記錄binlog，當確認需要刪除全表時，會產生很大量的binlog並佔用大量的undo數據塊，此時既沒有很好的效率也佔用了大量的資源。
使用truncate替代，不會記錄可恢復的信息，數據不能被恢復。也因此使用truncate操作有其極少的資源佔用與極快的時間。另外，使用truncate可以回收表的水位，使自增欄位值歸零。
7. 使用合理的分頁方式以提高分頁效率
使用合理的分頁方式以提高分頁效率 針對展現等分頁需求，合適的分頁方式能夠提高分頁的效率。
案例1：
select * from t where thread_id = 10000 and deleted = 0 
   order by gmt_create asc limit 0, 15;
上述例子通過一次性根據過濾條件取出所有欄位進行排序返回。數據訪問開銷=索引IO+索引全部記錄結果對應的表數據IO。因此，該種寫法越翻到後面執行效率越差，時間越長，尤其表數據量很大的時候。
適用場景：當中間結果集很小（10000行以下）或者查詢條件複雜（指涉及多個不同查詢欄位或者多表連接）時適用。
案例2：
select t.* from (select id from t where thread_id = 10000 and deleted = 0
   order by gmt_create asc limit 0, 15) a, t 
      where a.id = t.id; 
上述例子必須滿足t表主鍵是id列，且有覆蓋索引secondary key:(thread_id, deleted, gmt_create)。通過先根據過濾條件利用覆蓋索引取出主鍵id進行排序，再進行join操作取出其他欄位。數據訪問開銷=索引IO+索引分頁後結果（例子中是15行）對應的表數據IO。因此，該寫法每次翻頁消耗的資源和時間都基本相同，就像翻第一頁一樣。
適用場景：當查詢和排序欄位（即where子句和order by子句涉及的欄位）有對應覆蓋索引時，且中間結果集很大的情況時適用。
五、建表優化
1. 在表中建立索引，優先考慮where、order by使用到的欄位。
2. 儘量使用數字型欄位（如性別，男：1 女：2），若只含數值信息的欄位儘量不要設計為字符型，這會降低查詢和連接的性能，並會增加存儲開銷。
這是因為引擎在處理查詢和連接時會 逐個比較字符串中每一個字符，而對於數字型而言只需要比較一次就夠了。
3. 查詢數據量大的表 會造成查詢緩慢。主要的原因是掃描行數過多。這個時候可以通過程序，分段分頁進行查詢，循環遍歷，將結果合併處理進行展示。要查詢100000到100050的數據，如下：
SELECT * FROM (SELECT ROW_NUMBER() OVER(ORDER BY ID ASC) AS rowid,* 
   FROM infoTab)t WHERE t.rowid > 100000 AND t.rowid <= 100050
4. 用varchar/nvarchar 代替 char/nchar
儘可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長欄位存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的欄位內搜索效率顯然要高些。
不要以為 NULL 不需要空間，比如：char(100) 型，在欄位建立時，空間就固定了， 不管是否插入值（NULL也包含在內），都是佔用 100個字符的空間的，如果是varchar這樣的變長欄位， null 不佔用空間。

相關焦點

  • Mysql Limit 字句優化
    LIMIT字句常用的語法類似於:LIMIT m,n, 針對不同的情況, MySQL會對查詢做一些優化.Time: 0.240s可以看到遍歷的數量少時, 速度更快, LIMIT操作需要掃描的數據增加, 就需要通過一些方式來有優化.覆蓋索引優化當SELECT的欄位被某個索引覆蓋, 由於不需要回表查詢, 效率少許提升.
  • MySQL分頁優化解析
    在有索引的情況下，limit m,n速度足夠，可是在複雜條件搜索時，where somthing order by somefield+somefieldmysql會搜遍資料庫，找出「所有」符合條件的記錄，然後取出m,n條記錄。如果你的數據量有幾十萬條，用戶又搜索一些很通俗的詞，然後要依次讀最後幾頁重溫舊夢。mysql該很悲壯的不停操作硬碟。
  • mysql大表中count()的用法以及mysql中count()的優化
    本篇文章給大家帶來的內容是關於mysql大表中count()的用法以及mysql中count()的優化，有一定的參考價值，有需要的朋友可以參考一下，希望對你有所幫助。一個單表中包含有6000w+的數據,然而你又不能拆分.需要分別統計表中有多少數據,A產品有多少,B產品有多少這幾個數據.
  • MySQL優化原理分析及優化方案總結
    在我們的記憶儲備裡也早已記住了這些關鍵詞：避免使用SELECT*、避免使用NULL值的判斷、根據需求適當的建立索引、優化MySQL參數.但是你對於這些優化技巧是否真正的掌握了及其相應的工作原理是否吃透了呢？在我們的實際開發過程中你能充分應用到嗎？我覺得還有待考察。所以，本文將詳細介紹MySQL優化技巧以及其相應的技術原理，希望大家看完以後，能更清楚直接的了解這些優化方案，並應用到我們的工作崗位中。
  • MYSQL優化 學習筆記
    經常出現的以下：索引優化什麼是索引MySQL 官方對索引的定義為：索引（Index）是幫助 MySQL 高效獲取數據的數據結構。可以得到索引的本質： 索引是數據結構。所以要減少or的使用，可以使用 union all 或者 union 來替代關聯查詢優化1、INNER JOIN優化 inner join 時，mysql 會把i小結果集的表選為驅動表（小表驅動大表） 所以最好把索引建立在大表上2、LEFT JOIN、RIGHT JOIN優化即左外連接查詢索引建在右表，右外連接索引建在左表。
  • 超級實用的 MySQL 常用優化指南!
    MySQL實現分區的方式也意味著索引也是按照分區的子表定義，沒有全局索引mysql優化用戶的SQL語句是需要針對分區表做優化，SQL條件中要帶上分區條件的列，從而使查詢定位到少量的分區上，否則就會掃描全部分區，可以通過 EXPLAIN PARTITIONS 來查看某條SQL語句會落在那些分區上，從而進行SQL優化，如下圖5條記錄落在兩個分區上
  • MySQL 的索引是什麼?怎麼優化?
    MySQL提供了Explain，用於顯示SQL執行的詳細信息，可以進行索引的優化。1.硬體問題。如網絡速度慢，內存不足，I/O吞吐量小，磁碟空間滿了等。2.沒有索引或者索引失效。（一般在網際網路公司，DBA會在半夜把表鎖了，重新建立一遍索引，因為當你刪除某個數據的時候，索引的樹結構就不完整了。
  • MySQL優化指南
    ，大家可以參考以下步驟來優化：除非單表數據未來會一直不斷上漲，否則不要一開始就考慮拆分，拆分會帶來邏輯、部署、運維的各種複雜度。一般以整型值為主的表在千萬級以下，字符串為主的表在五百萬以下是沒有太大問題的，而事實上很多時候MySQL單表的性能依然有不少優化空間，甚至能正常支撐千萬級以上的數據量。
  • 「資料庫分享」MySQL資料庫優化
    A: 需要優化,則說明效率不夠理想.因此我們首先要做的,不是優化,而是---診斷.治病的前提,是診病,找出瓶頸所在.CPU,內存,IO? 峰值,單條語句?查看慢查詢日誌相關配置mysql> show variables like 'slow_query%';修改全局慢查詢日誌配置。
  • 史上最全的MySQL高性能優化實戰總結!
    1.3 優化思路1.3.1 優化什麼在資料庫優化上有兩個主要方面：即安全與性能。1.3.3 優化維度資料庫優化維度有四個:硬體、系統配置、資料庫表結構、SQL及索引優化選擇1.4 優化工具有啥？SHOW ENGINE INNODB STATUS Innodb   SHOW PROCESSLIST    explain             how index           slow-log            mysqldumpslow       不常用但好用的工具zabbix
  • MySQL 優化案例 - select count-愛可生
    mysql> create index idx_rowguid on api_runtime_log(rowguid);Query OK, 0 rows affected (0.01 sec)Records: 0 Duplicates: 0 Warnings: 0mysql> select count(*) from api_runtime_log;++| count(
  • PHP資料庫編程之MySQL優化策略概述
    為了提升PHP的運行效率，程式設計師不光需要寫出邏輯清晰，效率很高的代碼，還要能對query語句進行優化。雖然我們對資料庫的讀取寫入速度上卻是無能為力，但在一些資料庫類擴展像memcache、mongodb、redis這樣的數據存儲伺服器的幫助下，PHP也能達到更快的存取速度，所以了解學習這些擴展也是非常必要，這一篇先說一下MySQL常見的優化策略。
  • MySQL優化:學會使用show profile和trace分析慢查詢
    MySQL優化：定位慢查詢的兩種方法以及使用explain分析SQL在上一節我們學習了定位慢 SQL 及使用 explain 分析慢 SQL，我們也提到了分析慢 SQL 還有 show profile 和 trace 等方法，本節就重點補充學習這兩種方法。
  • MySQL的limit用法和分頁查詢的性能分析及優化
    不用擔心，mysql已經為我們提供了這樣一個功能。mysql> SELECT * FROM table LIMIT 5,10; // 檢索記錄行 6-15 //為了檢索從某一個偏移量到記錄集的結束所有的記錄行，可以指定第二個參數為 -1：mysql> SELECT * FROM table LIMIT 95,-1; // 檢索記錄行 96-last.
  • MySQL優化:定位慢查詢的兩種方法以及使用explain分析SQL
    確定慢查詢日誌路徑：mysql> show global variables like "datadir";確定慢查詢日誌文件名：mysql> show發現慢查詢及時優化或者提醒開發改寫。一般測試環境建議 long_query_time 設置的閥值比生產環境的小，比如生產環境是 1 秒，則測試環境建議配置成 0.5 秒。便於在測試環境及時發現一些效率低的 SQL。
  • mysql┃多個角度說明sql優化,讓你吊打面試官!
    的優化是我們經常都會提到的一個話題，也是重中之重，在很多大廠中會有專門的DBA來做這件事情，甚至更過分的是連應屆生的招聘崗位要求上都寫了需要懂一點sql優化，最近moon一直在寫關於mysql的文章，包括之前寫的索引相關，其實也都是為了這篇文章做個鋪墊，所以你懂了嗎，今天我將從表結構、索引、查詢語句、分庫分表這四個維度來和大家聊聊，在工作中，怎麼進行sql優化？
  • 面對MySQL 查詢索引失效,程式設計師的六大優化技巧!
    充分優化和利用索引能夠大大提高數據的查詢效率，但是在實際的應用中MySQL可能並不總會選擇合適且效率高的索引。經過分析器，mysql就知道你要做什麼了。SQL 在執行的過程中經過優化器，並由優化器生成 SQL 的執行計劃。
  • MySQL 性能優化之骨灰級,高階神技 !
    在進行MySQL的優化之前必須要了解的就是MySQL的查詢過程，很多的查詢優化工作實際上就是遵循一些原則讓MySQL的優化器能夠按照預想的合理方式運行而已。今天給大家講解MySQL的優化實戰，助你高薪之路順暢！二、優化的哲學注意：優化有風險，涉足需謹慎！
  • MySQL 全面優化,讓你的 MySQL 飛起來!
    2、優化的需求穩定性和業務可持續性，通常比性能更重要；優化不可避免涉及到變更，變更就有風險；優化使性能變好，維持和變差是等概率事件；切記優化，應該是各部門協同，共同參與的工作，任何單一部門都不能對資料庫進行優化！所以優化工作，是由業務需要驅使的！
  • PHP+MySQL實現對一段時間內每天數據統計優化操作實例
    （商務合作聯繫QQ號：2230304070）http://www.jb51.net/article/136685.htm這篇文章主要介紹了PHP+MySQL實現對一段時間內每天數據統計優化操作,結合具體實例形式分析了php針對mysql查詢統計相關優化操作技巧
  • 總結MySQL 8種性能優化方式
    索引的優缺點:優點：某些情況下使用select語句大幅度提高效率，合適的索引可以優化MySQL伺服器的查詢性能，從而起到優化MySQL的作用。缺點：表行數據的變化（index、update、delect），簡歷在表列上的索引也會自動維護，一定程度上會使DML操作變慢。索引還會佔用磁碟額外的存儲空間。