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分钟以上
现代化家居响应式网站模板源码是以cmseasy进行开发的家居网站模板。该软件可免费使用，模板附带测试数据！模板源码特点：整体采用浅色宽屏设计，简洁大气，电脑手机自适应布局，大方美观，功能齐全，值得推荐的一款模板，每个页面精心设计，美观大方，兼容各大浏览器；所有代码经过SEO优化，使网站更利于搜索引擎排名，是您做环保类网站的明确选择。无论是在电脑、平板、手机上都可以访问到排版合适的网站，即便是微信等
0
看到Copying to tmp table占据了大量的cpu运算。
看来，mysql优化器太弱了，又要我们强制使用索引了！force index(primary) ,强制使用pd表的主键
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
769
收藏
