[英]MySQL / MariaDB InnoDB indexes stops working
我从MySQL / MariaDB InnoDB / XtraDB中遇到奇怪的行为。 最近切换到了MariaDB 5.5。 切换使服务器整体上性能更高,但是我仍然遇到这个问题。
一个特定的表索引似乎有时会中断。 一段时间后,它会自行修复。
SHOW CREATE TABLE article_inventory;
给
CREATE TABLE `article_inventory` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
`article_variant_id` BIGINT(20) UNSIGNED NULL DEFAULT NULL,
`season_id` BIGINT(20) UNSIGNED NOT NULL,
`warehouse_id` BIGINT(20) UNSIGNED NOT NULL,
`quantity` BIGINT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
UNIQUE INDEX `unique_inventory_idx` (`article_variant_id`, `season_id`, `warehouse_id`),
INDEX `article_variant_id_idx` (`article_variant_id`),
INDEX `article_inventory_season_id_idx` (`season_id`),
INDEX `article_inventory_warehouse_id_idx` (`warehouse_id`),
CONSTRAINT `article_inventory_article_variant_id_article_variant_id` FOREIGN KEY (`article_variant_id`) REFERENCES `article_variant` (`id`),
CONSTRAINT `article_inventory_season_id_season_id` FOREIGN KEY (`season_id`) REFERENCES `season` (`id`),
CONSTRAINT `article_inventory_warehouse_id_warehouse_id` FOREIGN KEY (`warehouse_id`) REFERENCES `warehouse` (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
AUTO_INCREMENT=3827622858;
编辑: SELECT查询的大多数是针对此表进行的。 每小时都会进行重大更新。 有时非常大的更新。
运行此查询:
SELECT a.id
FROM article a
INNER JOIN article_variant a2
ON a.style_id = a2.style_id
INNER JOIN article_block a3
ON a2.po = a3.po
INNER JOIN color c
ON a2.color_id = c.id
INNER JOIN size s
ON a2.size_id = s.id
INNER JOIN article_group a4
ON a2.id = a4.article_variant_id AND (a4.season_id = 6)
INNER JOIN article_inventory a5
ON a2.id = a5.article_variant_id AND (((a5.warehouse_id = 5 OR a5.warehouse_id = 1) AND a5.season_id = 6))
INNER JOIN article_date a6
ON a.style_id = a6.style_id AND ((a6.pricelist_id = 5 AND a6.season_id = 6))
INNER JOIN article_price a7
ON a.style_id = a7.style_id AND ((a7.pricelist_id = 5 AND a7.season_id = 6))
INNER JOIN pricelist p
ON a7.pricelist_id = p.id
INNER JOIN concept c2
ON a4.concept_id = c2.id
INNER JOIN category c3
ON a4.category_id = c3.id
LEFT JOIN order_cart_row o
ON a2.id = o.article_variant_id AND (o.order_id = 17035)
LEFT JOIN shortlist s2
ON a.id = s2.article_id AND (s2.order_id = 17035)
WHERE ((a2.is_canceled <> 1 AND a4.is_canceled <> 1) OR o.quantity IS NOT NULL) AND c2.id = 2
GROUP BY a.id
...应该在大约0.5-1.0秒内执行,并给我一个类似于以下的解释:
id select_type table type possible_keys key key_len ref rowsExtra
1 SIMPLE p const PRIMARY PRIMARY 8 const 1 Using index; Using temporary; Using filesort
1 SIMPLE c2 const PRIMARY PRIMARY 8 const 1 Using index
1 SIMPLE a3 index PRIMARY PRIMARY 98 NULL 1031Using where
1 SIMPLE a2 ref PRIMARY,unique_variant_idx,color_id_idx,style_id_idx,size_id_idx,article_variant_po_idx article_variant_po_idx 98 wsp_stage.a3.po 14 Using where
1 SIMPLE s eq_ref PRIMARY PRIMARY 11 wsp_stage.a2.size_id 1 Using index
1 SIMPLE c eq_ref PRIMARY PRIMARY 11 wsp_stage.a2.color_id 1
1 SIMPLE o eq_ref unique_rows_idx,article_variant_id_idx,order_id_idx unique_rows_idx 16 const,wsp_stage.a2.id 1 Using index
1 SIMPLE a eq_ref unique_style_idx unique_style_idx 767 wsp_stage.a2.style_id 1 Using index
1 SIMPLE a6 ref article_season_pricelist_unique_idx,season_id_idx,pricelist_id_idx,style_id_idx article_season_pricelist_unique_idx 784 wsp_stage.a2.style_id,const,const 1 Using index
1 SIMPLE a7 ref article_season_pricelist_unique_idx,season_id_idx,pricelist_id_idx,style_id_idx article_season_pricelist_unique_idx 784 wsp_stage.a2.style_id,const,const 1 Using index
1 SIMPLE a4 eq_ref unique_group_idx,one_per_season_idx,category_id_idx,concept_id_idx,season_id_idx,article_variant_id_idx one_per_season_idx 16 wsp_stage.a2.id,const 1 Using index
1 SIMPLE c3 eq_ref PRIMARY PRIMARY 8 wsp_stage.a4.category_id 1 Using index
1 SIMPLE s2 ref shortlist_article_id_idx shortlist_article_id_idx 8 wsp_stage.a.id 10 Using where
1 SIMPLE a5 ref unique_inventory_idx,article_variant_id_idx,article_inventory_season_id_idx,article_inventory_warehouse_id_iunique_inventory_idx 17 wsp_stage.a2.id,const 8 Using where
当一切正常运行时,article_inventory(别名a5)使用unique_inventory_idx
或article_variant_id_idx
。 两者都应该给我大约5-100条检查过的行。
但是,时不时地发生某些事情,并且相同的查询最多需要30秒的时间,并为我提供了以下解释:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE p const PRIMARY PRIMARY 8 const 1 Using index; Using temporary; Using filesort
1 SIMPLE c2 const PRIMARY PRIMARY 8 const 1 Using index
1 SIMPLE a5 ref unique_inventory_idx,article_variant_id_idx,article_inventory_season_id_idx,article_inventory_warehouse_id_iarticle_inventory_season_id_idx 8 const 6718732 Using where
1 SIMPLE a4 eq_ref unique_group_idx,one_per_season_idx,category_id_idx,concept_id_idx,season_id_idx,article_variant_id_idx one_per_season_idx 16 wsp_stage.a5.article_variant_id,const1 Using where
1 SIMPLE c3 eq_ref PRIMARY PRIMARY 8 wsp_stage.a4.category_id 1 Using index
1 SIMPLE a2 eq_ref PRIMARY,unique_variant_idx,color_id_idx,style_id_idx,size_id_idx,article_variant_po_idx PRIMARY 8 wsp_stage.a5.article_variant_id 1
1 SIMPLE c eq_ref PRIMARY PRIMARY 11 wsp_stage.a2.color_id 1 Using index
1 SIMPLE a eq_ref unique_style_idx unique_style_idx 767 wsp_stage.a2.style_id 1 Using index
1 SIMPLE a6 ref article_season_pricelist_unique_idx,season_id_idx,pricelist_id_idx,style_id_idx article_season_pricelist_unique_idx 784 wsp_stage.a2.style_id,const,const 1 Using index
1 SIMPLE a7 ref article_season_pricelist_unique_idx,season_id_idx,pricelist_id_idx,style_id_idx article_season_pricelist_unique_idx 784 wsp_stage.a2.style_id,const,const 1 Using index
1 SIMPLE s eq_ref PRIMARY PRIMARY 11 wsp_stage.a2.size_id 1 Using index
1 SIMPLE a3 eq_ref PRIMARY PRIMARY 98 wsp_stage.a2.po 1 Using index
1 SIMPLE o eq_ref unique_rows_idx,article_variant_id_idx,order_id_idx unique_rows_idx 16 const,wsp_stage.a5.article_variant_id1 Using where
1 SIMPLE s2 ref shortlist_article_id_idx shortlist_article_id_idx 8 wsp_stage.a.id 7 Using where
article_inventory
(a5)现在正在使用article_inventory_season_id_idx
。 索引非常差,因为它是所有索引中的第二个最不明确的索引。 给我6718732检查行。
my.ini:
[mysqld]
datadir="W:/mariadb/data/"
port=3306
sql_mode="STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
default_storage_engine=innodb
innodb_buffer_pool_size=5000M
innodb_log_file_size=52428800
innodb_file_per_table
innodb_file_format=Barracuda
[client]
port=3307
首先,索引没有中断。 这可能与表上的MySQL统计信息有关,建议查询优化器使用错误的索引。 现在,在我们探讨可能的解决方案之前,让我们首先了解造成问题的原因。
MySQL运行查询时,它将查看该表的统计信息以确定哪些索引适合该查询,然后根据建议选择正确的索引。 表统计信息包含诸如索引基数和与使用索引相关的成本之类的信息。 MySQL每次运行查询时都会查看这些统计信息,以确定最佳的执行路径。
现在,由于索引是在更新时存储在磁盘上的实际数据结构,因此可以从这些索引中插入和删除它们的统计信息。 这可能是问题的根本原因。 InnoDB通过对索引结构进行8次随机深入分析来即时更新统计信息。 MyISAM的做法有所不同。 有关此问题的更多信息,请参见此链接: https : //dba.stackexchange.com/questions/3398/from-where-does-the-mysql-query-optimizer-read-index-statistics
您提到您不时做一次重复较大的插入操作。 我怀疑在插入期间或插入发生之后,有一小段时间,该表的innodb统计信息已过期或正在编译。 这可能就是为什么您会看到从一个索引到传染性索引的零星变化的原因。 那时您的统计信息不正确,查询优化器做出了错误的选择。
去谷歌以下:
mysql statistics update
有一堆链接,其中包含有关此内容的更多详细信息,这是一本不错的书。
我以前在数据库上看到过这种情况,这不是一个错误,只是需要注意的事情。
可能的解决方案:
我希望如果您需要更多说明,请发表评论。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.