Edit:忽略这个问题,这与我在桌子上的表现不佳有关,而与下面描述的实际数据库设计无关。
mariadb10.11.10我在一个带有一个自定义桌子(我创建的一个自定义桌子的灯堆)上有一个Zen Cart电子商务网站(我相信Oscommerce的变体)加入了核心产品的
TRIGGER
表。 这是在正常操作期间没有性能问题的生产系统上运行的,作为一个电子商务网站,在这些相同表格上执行的相同表中的查询大多是选择的。 我在运行更新查询以将products_sort_order字段更改为新值时遇到困难。 所有字段均为索引,在两个表中索引了连接列
products
,并且我在Where子句中指定的三个VARCHAR字段也被索引。 两张桌子都使用相同的引擎Myisam。 为什么此更新查询如此慢?
products_id
4.566第二查询执行时间是问题。
Edit:要清楚,我相信查询中使用的四个字段应索引,索引,如下所示。 这些是:
products_id(in
MariaDB [premier158]> UPDATE products p
-> INNER JOIN product_premier_extra pe USING (products_id)
-> SET products_sort_order = 1000
-> WHERE model = 'splashback'
-> AND style = 'digital'
-> AND variation = 'Liquid Lava';
Query OK, 0 rows affected (4.566 sec)
Rows matched: 51 Changed: 0 Warnings: 0
和
products
)
product_premier_extra
)
风格(在
product_premier_extra
估计(在
product_premier_extra
product_premier_extra
EXPLAIN
explain UPDATE products p
INNER JOIN product_premier_extra pe USING (products_id)
SET products_sort_order = 1000
WHERE model = 'splashback'
AND style = 'digital'
AND variation = 'Liquid Lava';
1 SIMPLE pe ref idx_product_premier_id,idx_product_premier_extra_fields idx_product_premier_extra_fields 906 const,const,const 32 Using where
1 SIMPLE p eq_ref PRIMARY PRIMARY 4 premier158.pe.products_id 1
上是1:1的关系),所以不是很大的体积。创建表输出显示了索引,重要的是
products_id
在两者中都索引,其他三个字段
products_id
,
model
,style
,在加入表中也有索引(请参阅在上面的解释计划中使用
variation
)。 所有这些列都是product_premier_extra
。
我读了与查询缓慢有关的各种其他帖子,它往往降低到两种情况下,1/索引数据不良数据2/大量数据,发动机不适合或配置不佳。 这里似乎都不是这样。 所使用的系统是高性能的,没有潜在的硬件问题。
我应该在哪里看这个性能问题?
Edit:为了澄清,涉及的查询在某些语句中表现良好,例如,从子桌间选择匹配行::
:
idx_product_premier_extra_fields
因此,在该桌子上是0.001秒。 同样,如果我从第二个表中选择所有
NOT NULL
值并为他们查询第一表,就像product_premier_extra
> select * from product_premier_extra
WHERE
model = 'splashback'
AND style = 'digital'
AND variation = 'Liquid Lava';
[.. cut output ..]
51 rows in set (0.001 sec)
将两个选择的语句组合到我遇到的更新相同类型的子句中,也可以很好地执行:
products_id
SOSELECT语句看起来不错,只有当我将Select转换为更新时,突然需要5秒才能执行。
我将在此处给创建表输出,但是很长:
INNER JOIN
> select * from products where products_id in ([.. cut 51 ID values ..]);
51 rows in set (0.000 sec)
所有人,所有人都证明这是我的错。 查询似乎表现不佳,因为我在
> SELECT products_sort_order
-> FROM products p
-> INNER JOIN product_premier_extra pe USING (products_id)
-> WHERE model = 'splashback'
-> AND style = 'digital'
-> AND variation = 'Liquid Lava';
[.. cut 51 rows of output ..]
51 rows in set (0.001 sec)
上表的执行计划(
CREATE TABLE `products` (
`products_id` int(11) NOT NULL AUTO_INCREMENT,
`products_type` int(11) NOT NULL DEFAULT 1,
`products_quantity` float NOT NULL DEFAULT 0,
`products_model` varchar(64) DEFAULT NULL,
`products_image` varchar(255) DEFAULT NULL,
`products_price` decimal(15,4) NOT NULL DEFAULT 0.0000,
`products_virtual` tinyint(1) NOT NULL DEFAULT 0,
`products_date_added` datetime NOT NULL DEFAULT '0001-01-01 00:00:00',
`products_last_modified` datetime DEFAULT NULL,
`products_date_available` datetime DEFAULT NULL,
`products_weight` float NOT NULL DEFAULT 0,
`products_status` tinyint(1) NOT NULL DEFAULT 0,
`products_tax_class_id` int(11) NOT NULL DEFAULT 0,
`manufacturers_id` int(11) DEFAULT NULL,
`products_ordered` float NOT NULL DEFAULT 0,
`products_quantity_order_min` float NOT NULL DEFAULT 1,
`products_quantity_order_units` float NOT NULL DEFAULT 1,
`products_priced_by_attribute` tinyint(1) NOT NULL DEFAULT 0,
`product_is_free` tinyint(1) NOT NULL DEFAULT 0,
`product_is_call` tinyint(1) NOT NULL DEFAULT 0,
`products_quantity_mixed` tinyint(1) NOT NULL DEFAULT 0,
`product_is_always_free_shipping` tinyint(1) NOT NULL DEFAULT 0,
`products_qty_box_status` tinyint(1) NOT NULL DEFAULT 1,
`products_quantity_order_max` float NOT NULL DEFAULT 0,
`products_sort_order` int(11) NOT NULL DEFAULT 0,
`products_discount_type` tinyint(1) NOT NULL DEFAULT 0,
`products_discount_type_from` tinyint(1) NOT NULL DEFAULT 0,
`products_price_sorter` decimal(15,4) NOT NULL DEFAULT 0.0000,
`master_categories_id` int(11) NOT NULL DEFAULT 0,
`products_mixed_discount_quantity` tinyint(1) NOT NULL DEFAULT 1,
`metatags_title_status` tinyint(1) NOT NULL DEFAULT 0,
`metatags_products_name_status` tinyint(1) NOT NULL DEFAULT 0,
`metatags_model_status` tinyint(1) NOT NULL DEFAULT 0,
`metatags_price_status` tinyint(1) NOT NULL DEFAULT 0,
`metatags_title_tagline_status` tinyint(1) NOT NULL DEFAULT 0,
`products_sku` varchar(30) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
PRIMARY KEY (`products_id`),
KEY `idx_products_date_added_zen` (`products_date_added`),
KEY `idx_products_status_zen` (`products_status`),
KEY `idx_products_date_available_zen` (`products_date_available`),
KEY `idx_products_ordered_zen` (`products_ordered`),
KEY `idx_products_model_zen` (`products_model`),
KEY `idx_products_price_sorter_zen` (`products_price_sorter`),
KEY `idx_master_categories_id_zen` (`master_categories_id`),
KEY `idx_products_sort_order_zen` (`products_sort_order`),
KEY `idx_manufacturers_id_zen` (`manufacturers_id`),
KEY `idx_products_products_sku` (`products_sku`)
) ENGINE=MyISAM AUTO_INCREMENT=32083 DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci
)和数据库设计不是全部图片。 我忘记了涉及数据库的另一种修改(两年前我写的Soundex搜索插件都在表上触发了一个触发器,以维护与某些字段中与单词相关的Soundex数据,请参阅
Https:// www.zen-cart.com/showthread.php?229817-soundex-search-searporport-thread)。 当我将该插件的卸载过程运行到数据库时,更新表现良好,解决了我的问题。 我当然会尝试研究出了问题。
因此,这里要接受的教训是,当一个CREATE TABLE `product_premier_extra` (
`products_id` int(11) NOT NULL,
`features` varchar(3000) NOT NULL,
`specifications` varchar(3000) NOT NULL,
`dimensions` varchar(3000) NOT NULL,
`diagram` varchar(100) NOT NULL,
`model` varchar(100) NOT NULL,
`style` varchar(100) NOT NULL,
`variation` varchar(100) NOT NULL,
`width` int(11) DEFAULT NULL,
`height` int(11) DEFAULT NULL,
UNIQUE KEY `idx_product_premier_id` (`products_id`),
KEY `idx_product_premier_extra_fields` (`model`,`style`,`variation`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci
的表现似乎远比类似的陈述要差得多时,人们可以认为在数据库引擎中引用了UPDATE
或其他次要操作。想:)