Moo*_*oon 5 mysql sql wordpress query-optimization limit
我正在尝试分析为什么以下查询速度较慢 LIMIT 0,1比LIMIT 0,100
我已经添加 SQL_NO_CACHE用于测试目的。
询问:
SELECT
SQL_NO_CACHE SQL_CALC_FOUND_ROWS wp_posts.*,
low_stock_amount_meta.meta_value AS low_stock_amount
FROM
wp_posts
LEFT JOIN wp_wc_product_meta_lookup wc_product_meta_lookup ON wp_posts.ID = wc_product_meta_lookup.product_id
LEFT JOIN wp_postmeta AS low_stock_amount_meta ON wp_posts.ID = low_stock_amount_meta.post_id
AND low_stock_amount_meta.meta_key = '_low_stock_amount'
WHERE
1 = 1
AND wp_posts.post_type IN ('product', 'product_variation')
AND (
(wp_posts.post_status = 'publish')
)
AND wc_product_meta_lookup.stock_quantity IS NOT NULL
AND wc_product_meta_lookup.stock_status IN('instock', 'outofstock')
AND (
(
low_stock_amount_meta.meta_value > ''
AND wc_product_meta_lookup.stock_quantity <= CAST(
low_stock_amount_meta.meta_value AS SIGNED
)
)
OR (
(
low_stock_amount_meta.meta_value IS NULL
OR low_stock_amount_meta.meta_value <= ''
)
AND wc_product_meta_lookup.stock_quantity <= 2
)
)
ORDER BY
wp_posts.ID DESC
LIMIT
0, 1
Run Code Online (Sandbox Code Playgroud)
解释显示完全相同的输出
1 SIMPLE wp_posts index PRIMARY,type_status_date PRIMARY 8 NULL 27071 Using where
1 SIMPLE low_stock_amount_meta ref post_id,meta_key meta_key 767 const 1 Using where
1 SIMPLE wc_product_meta_lookup eq_ref PRIMARY,stock_status,stock_quantity,product_id PRIMARY 8 woocommerce-admin.wp_posts.ID 1 Using where
Run Code Online (Sandbox Code Playgroud)
平均查询时间为 350ms LIMIT 0,1
平均查询时间为 7ms LIMIT 0,100
查询性能开始变得更快 LIMIT 0,17
我已经按照这个问题中的建议在 order by 子句中添加了另一列,但这会Using filesort在解释输出中触发
Order by wp_posts.post_date, wp_posts.ID desc
1 SIMPLE wp_posts ALL PRIMARY,type_status_date NULL NULL NULL 27071 Using where; Using filesort
1 SIMPLE low_stock_amount_meta ref post_id,meta_key meta_key 767 const 1 Using where
1 SIMPLE wc_product_meta_lookup eq_ref PRIMARY,stock_status,stock_quantity,product_id PRIMARY 8 woocommerce-admin.wp_posts.ID 1 Using where
Run Code Online (Sandbox Code Playgroud)
有没有办法在不改变索引的情况下解决它,为什么会发生这种情况?
同样有趣的是,查询时间从LIMIT 0,17. 我不确定为什么 17 在这里是一个神奇的数字。
更新 1:我刚刚尝试添加FORCE INDEX(PRIMARY),现在LIMIT 0,100具有与LIMIT 0,1smh相同的性能
wp_postmeta有草率的索引;这会减慢大多数涉及它的查询。
O. Jones 和我制作了一个WordPress 插件来改进 postmeta 的索引。我们检测各种各样的东西,比如 Barracuda 版本的 InnoDB 存储引擎和其他 MySQL 的存在,并做正确的事情。
这可能会加速所有三个平均值。它很可能会改变EXPLAINs。
| 归档时间: |
|
| 查看次数: |
112 次 |
| 最近记录: |