影響結果集不是輸出結果數，不是查詢返回的記錄數，而是索引所掃瞄的結果數
範例：select * from user where area=』廈門』and ***=』女』假設索引為area假設user表中area=』廈門』的有125000條，而搜尋返回結果為60233條。影響結果集是125000條，索引先命中125000條廈門使用者，再遍歷以***=』女』進行篩選操作，得到60233條結果。
如果該sql 增加limit 0,30的字尾。查詢時，先命中area=』廈門』，然後依順序執行***=』女』篩選操作，直到滿足可以返回30條為止，所涉及記錄數未知。除非滿足條件的結果不足30條，否則不會遍歷125000條記錄。
但是如果sql中涉及了排序操作，比如order by lastlogin desc 再有limit 0,30時，排序需要遍歷所有area=』廈門』的記錄，而不是滿足即止。
如果索引與查詢條件和排序條件完全命中，影響結果集就是limit後面的數字（$start + $end），比如：limit 200,30 影響結果集是230. 而不是30.
如果索引只命中部分查詢條件，甚至無命中條件，在無排序條件情況下，會在索引命中的結果集中遍歷到滿足所有其他條件為止。
比如
select * from user limit 10; 雖然沒用到索引，但是因為不涉及二次篩選和排序，系統直接返回前10條結果，影響結果集依然只有10條，就不存在效率影響。如果搜尋所包含的排序條件沒有被索引命中，則系統會遍歷是所有索引所命中的結果，並且排序。
例如
select * from user order by timeline desc limit 10; 如果timeline不是索引，影響結果集是全表，就存在需要全表資料排序，這個效率影響就巨大。再比如select * from user where area=』廈門』order by timeline desc limit 10; 如果area是索引，而 area + timeline 未建立索引，則影響結果集是所有命中area=』廈門』的使用者，然後在影響結果集內排序。
論壇翻頁優化
背景，常見論壇帖子頁sql:select * from post where tagid=$tagid order by lastpost limit $start, $end翻頁。索引為tagid+lastpost 復合索引挑戰，超級熱帖，幾萬回帖，使用者頻頻翻到末頁，limit 25770,30 乙個操作下來，影響結果集巨大(25770+30)，查詢緩慢。
解決方法：
只涉及上下翻頁情況每次查詢的時候將該頁查詢結果中最大的las
tpos
t和最小
的分別記
錄為
lastpost和最小的分別記錄為
lastpo
st和最
小的分別
記錄為minlastpost 和$maxlastpost ，使用這種方式，影響結果集只有30條，效率極大提公升。
上翻頁查詢為
select
*from post where tagid=$tagid and lastpost<$minlastpost order
by lastpost desc
limit
30;
下翻頁為
select
*from post where tagid=$tagid and lastpost>$maxlastpost order
by lastpost limit
30;
涉及跳轉到任意頁:網際網路上常見的乙個優化方案可以這樣表述，
select * from post where tagid=$tagid and lastpost>=(select lastpost from post where tagid=$tagid order by lastpost limit $start,1) order by lastpost limit 30; 或者select * from post where pid in (select pid from post where tagid=$tagid order by lastpost limit $start,30);(第2條s語法在新的mysql版本已經不支援，新版本mysql in的子語句不再支援limit條件，但可以分解為兩條sql實現，原理不變，不做贅述)以上思路在於，子查詢的影響結果集仍然是$start +30，但是資料獲取的過程（sending data狀態）發生在索引檔案中，而不是資料表檔案，這樣所需要的系統開銷就比前一種普通的查詢低乙個數量級，而主查詢的影響結果集只有30條，幾乎無開銷。但是切記，這裡仍然涉及了太多的影響結果集操作。
延伸問題：來自於uchome典型查詢
select * from uchome_thread where tagid='73820' order by displayorder desc, lastpost desclimit $start,30;如果換用如上方法，
上翻頁**
select * from uchome_thread where tagid='73820' and lastpost<$minlastpost order by displayorder desc,lastpost desclimit 0,30;下 翻 頁 代 碼
select * from uchome_thread where tagid='73820' and lastpost>$maxlastpost order by displayorder desc, lastpost asclimit 0,30;==這裡涉及乙個order by 索引可用性問題，當order by中復合索引的字段，乙個是asc，乙個是desc 時，其排序無法在索引中完成。所以只有上翻頁可以正確使用索引，影響結果集為30。下翻頁無法在排序中正確使用索引，會命中所有索引內容然後排序，效率低下。
*2023年2月24日09:11:46
mysql效能優化 mysql效能優化
優化方式 1.空間換時間 冗餘 2.時間換空間 字段優先使用型別 int date char varchar text 索引型別 btree索引 hash索引 索引的葉子下，存放乙個資訊指向所在行的資料位址。btree有利於範圍查詢，hash有利於精確查詢。btree用的更多一些。btree索引的常...
mysql的效能優化 mysql效能優化
檢視安裝指令碼 select version 非互動式超時時間，如jdbc show global variables like wait timeout 互動式超時時間，如資料庫工具 show global variables like interactive timeout show sessi...
mysql 效能優化 命令 mysql效能優化
發現問題 當發現程式執行比較慢的時候，首先排除物力資源問題之後，就將注意力轉向mysq資料庫 1 首先確定執行慢的sql語句 mysql show full processlist 2 確認低效的查詢 多次執行第一步發現time耗費大的sql語句。檢視耗費的時間。3 分析效能 為sql生成乙個執行計...