products表。 这是在正常操作期间没有性能问题的生产系统上运行的，作为一个电子商务网站，在这些相同表格上执行的相同表中的查询大多是选择的。 我在运行更新查询以将products_sort_order字段更改为新值时遇到困难。 所有字段均为索引，在两个表中索引了连接列
products_id，并且我在Where子句中指定的三个VARCHAR字段也被索引。 两张桌子都使用相同的引擎Myisam。 为什么此更新查询如此慢？
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
4.566第二查询执行时间是问题。
Edit：要清楚，我相信查询中使用的四个字段应索引，索引，如下所示。 这些是：
products_id（in
products和
product_premier_extra）
product_premier_extra）
风格（在
product_premier_extra估计（在
product_premier_extraEXPLAINexplain 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
products_id
上是1：1的关系），所以不是很大的体积。创建表输出显示了索引，重要的是
products_id在两者中都索引，其他三个字段
model，
stylevariation，在加入表中也有索引（请参阅在上面的解释计划中使用
product_premier_extraidx_product_premier_extra_fields我应该在哪里看这个性能问题？
Edit：为了澄清，涉及的查询在某些语句中表现良好，例如，从子桌间选择匹配行：：
：
NOT NULL因此，在该桌子上是0.001秒。 同样，如果我从第二个表中选择所有
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
将两个选择的语句组合到我遇到的更新相同类型的子句中，也可以很好地执行：
INNER JOINSOSELECT语句看起来不错，只有当我将Select转换为更新时，突然需要5秒才能执行。
我将在此处给创建表输出，但是很长：
> 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
上表的执行计划（
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
）和数据库设计不是全部图片。 我忘记了涉及数据库的另一种修改（两年前我写的Soundex搜索插件都在表上触发了一个触发器，以维护与某些字段中与单词相关的Soundex数据，请参阅
Https：// www.zen-cart.com/showthread.php?229817-soundex-search-searporport-thread）。 当我将该插件的卸载过程运行到数据库时，更新表现良好，解决了我的问题。 我当然会尝试研究出了问题。
因此，这里要接受的教训是，当一个UPDATE