全文索引对索引选择的干扰-mysql教程-PHP中文網

首頁

資料庫

mysql教程

全文索引对索引选择的干扰

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB

Jun 07, 2016 pm 05:36 PM

mysql全文索引使用得到，对性能提升有一定帮助；但是，若使用不得到，将会是异常灾难；mysql全文索引对整个优化器的索引选择都有干扰。看我生产环境下优化过的一

mysql全文索引使用得到，对性能提升有一定帮助；但是，若使用不得到，将会是异常灾难；mysql全文索引对整个优化器的索引选择都有干扰。看我生产环境下优化过的一条sql

SELECT DISTINCT pc.products_id, pd.products_name,p.products_date_added,pso.products_id FROM products_to_categories AS pc LEFT JOIN products_description AS pd ON pd.products_id=pc.products_id LEFT JOIN products AS p ON p.products_id=pd.products_id LEFT JOIN specials AS sps ON sps.products_id=p.products_id LEFT JOIN temp_products_7days_orders_amount AS 7days ON 7days.products_id=pc.products_id LEFT JOIN products_realtime_quantity AS prq ON prq.sku_or_poa = p.products_model LEFT JOIN products_stockout AS pso ON pso.products_id=pd.products_id WHERE p.products_status=1 AND (prq.msg != 'Temporary out stock.' OR ISNULL(prq.msg)) AND pc.categories_id IN ( 153,323,1055,1241,1431) AND MATCH(pd.products_name) AGAINST('*iphone*' IN BOOLEAN MODE) AND MATCH(pd.products_name) AGAINST('*c*' IN BOOLEAN MODE) ORDER BY 7days.orders_sum DESC

这条语句执行非常慢，经常出现卡住情况,有时候发现执行需要几分钟,而结果才几条，该语句也为涉及到大结果运算，各种连表条件上上都有索引。唯一特殊的地方就是pd.products_name为全文索引，而且执行的过程中pc.categories_id优先级高于pd.products_name全文索引，导致使用了pc.categories_id索引。按理来讲，这样也没有多大关系。但是explain后发现了问题

+----+-------------+-------+----------+-----------------------+-------------------+---------+---------------------------+------+----------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+----------+-----------------------+-------------------+---------+---------------------------+------+----------------------------------------------+ | 1 | SIMPLE | pc | range | PRIMARY,categories_id | categories_id | 4 | NULL | 307 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | pd | fulltext | PRIMARY,products_name | products_name | 0 | | 1 | Using where | | 1 | SIMPLE | p | eq_ref | PRIMARY | PRIMARY | 4 | banggood.pd.products_id | 1 | Using where | | 1 | SIMPLE | sps | ref | products_id | products_id | 4 | banggood.pd.products_id | 16 | Using index | | 1 | SIMPLE | 7days | ref | PRIMARY | PRIMARY | 4 | banggood.p.products_id | 1032 | | | 1 | SIMPLE | prq | ref | ix_prg_sku_or_poa | ix_prg_sku_or_poa | 152 | banggood.p.products_model | 10 | Using where | | 1 | SIMPLE | pso | eq_ref | PRIMARY | PRIMARY | 4 | banggood.pd.products_id | 1 | Using index | +----+-------------+-------+----------+-----------------------+-------------------+---------+---------------------------+------+----------------------------------------------+

我们发现驱动表示pc表，使用了categories_id索引，可能优化器优先选择了它，但是再看pd表，

按理来讲，这个时候pd表应该使用products_id索引，也就是这个表的primary key，但是优化器却选择了products_name全文索引，坑爹了！

profiling这条语句，执行时间为2分钟以上

+-------------------------+------------+-----------+------------+--------------+---------------+ | Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out | +-------------------------+------------+-----------+------------+--------------+---------------+ | starting | 0.000415 | 0.000000 | 0.000000 | 0 | 0 | | checking permissions | 0.000011 | 0.000000 | 0.000000 | 0 | 0 | | checking permissions | 0.000004 | 0.000000 | 0.000000 | 0 | 0 | | checking permissions | 0.000002 | 0.000000 | 0.000000 | 0 | 0 | | checking permissions | 0.000003 | 0.000000 | 0.000000 | 0 | 0 | | checking permissions | 0.000056 | 0.001000 | 0.000000 | 0 | 0 | | checking permissions | 0.000006 | 0.000000 | 0.000000 | 0 | 0 | | checking permissions | 0.000009 | 0.000000 | 0.000000 | 0 | 0 | | Opening tables | 0.000225 | 0.000000 | 0.000000 | 0 | 0 | | System lock | 0.000029 | 0.000000 | 0.000000 | 0 | 0 | | init | 0.000138 | 0.000000 | 0.000000 | 0 | 0 | | optimizing | 0.000046 | 0.000000 | 0.000000 | 0 | 0 | | statistics | 0.001115 | 0.001000 | 0.000000 | 0 | 0 | | preparing | 0.001246 | 0.002000 | 0.000000 | 0 | 0 | | FULLTEXT initialization | 0.000088 | 0.000000 | 0.000000 | 0 | 0 | | Creating tmp table | 0.000057 | 0.000000 | 0.000000 | 0 | 0 | | executing | 0.000005 | 0.000000 | 0.000000 | 0 | 0 | | Copying to tmp table | 120.430834 | 81.227651 | 38.749110 | 1112 | 0 | | Sorting result | 0.000058 | 0.000000 | 0.000000 | 0 | 0 | | Sending data | 0.000026 | 0.000000 | 0.000000 | 0 | 0 | | end | 0.000007 | 0.000000 | 0.000000 | 0 | 0 | | removing tmp table | 0.000015 | 0.000000 | 0.000000 | 0 | 0 | | end | 0.000041 | 0.001000 | 0.000000 | 0 | 0 | | query end | 0.000007 | 0.000000 | 0.000000 | 0 | 0 | | closing tables | 0.000023 | 0.000000 | 0.000000 | 0 | 0 | | freeing items | 0.008546 | 0.000000 | 0.007999 | 0 | 0 | | logging slow query | 0.000008 | 0.000000 | 0.000000 | 0 | 0 | | logging slow query | 0.000007 | 0.000000 | 0.000000 | 0 | 0 | | cleaning up | 0.000008 | 0.000000 | 0.000000 | 0 | 0 | +-------------------------+------------+-----------+------------+--------------+---------------+

看到Copying to tmp table占据了大量的cpu运算。

看来，mysql优化器太弱了，又要我们强制使用索引了！force index(primary) ,强制使用pd表的主键

陳述

本文內容由網友自願投稿，版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容，請聯絡admin@php.cn

MySQL：世界上最受歡迎的數據庫的簡介Apr 12, 2025 am 12:18 AM

MySQL是一種開源的關係型數據庫管理系統，主要用於快速、可靠地存儲和檢索數據。其工作原理包括客戶端請求、查詢解析、執行查詢和返回結果。使用示例包括創建表、插入和查詢數據，以及高級功能如JOIN操作。常見錯誤涉及SQL語法、數據類型和權限問題，優化建議包括使用索引、優化查詢和分錶分區。

MySQL的重要性：數據存儲和管理Apr 12, 2025 am 12:18 AM

MySQL是一個開源的關係型數據庫管理系統，適用於數據存儲、管理、查詢和安全。 1.它支持多種操作系統，廣泛應用於Web應用等領域。 2.通過客戶端-服務器架構和不同存儲引擎，MySQL高效處理數據。 3.基本用法包括創建數據庫和表，插入、查詢和更新數據。 4.高級用法涉及復雜查詢和存儲過程。 5.常見錯誤可通過EXPLAIN語句調試。 6.性能優化包括合理使用索引和優化查詢語句。

為什麼要使用mysql？利益和優勢Apr 12, 2025 am 12:17 AM

選擇MySQL的原因是其性能、可靠性、易用性和社區支持。 1.MySQL提供高效的數據存儲和檢索功能，支持多種數據類型和高級查詢操作。 2.採用客戶端-服務器架構和多種存儲引擎，支持事務和查詢優化。 3.易於使用，支持多種操作系統和編程語言。 4.擁有強大的社區支持，提供豐富的資源和解決方案。

描述InnoDB鎖定機制（共享鎖，獨家鎖，意向鎖，記錄鎖，間隙鎖，下一鍵鎖）。Apr 12, 2025 am 12:16 AM

InnoDB的鎖機制包括共享鎖、排他鎖、意向鎖、記錄鎖、間隙鎖和下一個鍵鎖。 1.共享鎖允許事務讀取數據而不阻止其他事務讀取。 2.排他鎖阻止其他事務讀取和修改數據。 3.意向鎖優化鎖效率。 4.記錄鎖鎖定索引記錄。 5.間隙鎖鎖定索引記錄間隙。 6.下一個鍵鎖是記錄鎖和間隙鎖的組合，確保數據一致性。

MySQL查詢性能差的常見原因是什麼？Apr 12, 2025 am 12:11 AM

MySQL查询性能不佳的原因主要包括没有使用索引、查询优化器选择错误的执行计划、表设计不合理、数据量过大和锁竞争。1.没有索引导致查询缓慢，添加索引后可显著提升性能。2.使用EXPLAIN命令可以分析查询计划，找出优化器错误。3.重构表结构和优化JOIN条件可改善表设计问题。4.数据量大时，采用分区和分表策略。5.高并发环境下，优化事务和锁策略可减少锁竞争。

您什麼時候應該使用複合索引與多個單列索引？Apr 11, 2025 am 12:06 AM

在數據庫優化中，應根據查詢需求選擇索引策略：1.當查詢涉及多個列且條件順序固定時，使用複合索引；2.當查詢涉及多個列但條件順序不固定時，使用多個單列索引。複合索引適用於優化多列查詢，單列索引則適合單列查詢。

如何識別和優化MySQL中的慢速查詢？（慢查詢日誌，performance_schema）Apr 10, 2025 am 09:36 AM

要優化MySQL慢查詢，需使用slowquerylog和performance_schema：1.啟用slowquerylog並設置閾值，記錄慢查詢；2.利用performance_schema分析查詢執行細節，找出性能瓶頸並優化。

MySQL和SQL：開發人員的基本技能Apr 10, 2025 am 09:30 AM

MySQL和SQL是開發者必備技能。 1.MySQL是開源的關係型數據庫管理系統，SQL是用於管理和操作數據庫的標準語言。 2.MySQL通過高效的數據存儲和檢索功能支持多種存儲引擎，SQL通過簡單語句完成複雜數據操作。 3.使用示例包括基本查詢和高級查詢，如按條件過濾和排序。 4.常見錯誤包括語法錯誤和性能問題，可通過檢查SQL語句和使用EXPLAIN命令優化。 5.性能優化技巧包括使用索引、避免全表掃描、優化JOIN操作和提升代碼可讀性。

See all articles