好的，要编辑我的答案以首先更具体地处理您的查询，早期的建议会起作用，但您的查询相当疯狂，所以让我们讨论一下原因。
您需要的一切实际上都在此处的 EXPLAIN 输出中，您的 UNION 导致 340 万次元组访问，而派生表查询（连接后）约为 90 万。
在两个表中的 PRODUCTNAME 上添加索引
联盟？什么？我假设这里发生的事情是您有两个非常相似/相同的表，并且您正在对这个相当狡猾的过滤器查询进行 UNION，以基本上将一个表连接到另一个表。这是第一个警告标志，如果您可以简化此查询并拥有一个具有类型枚举的表，例如 (LS|CJ) 或外键和类型表，则此查询会更快，type具体取决于您的要求。
假设您出于某种原因不想永久执行此操作（并且您应该这样做），您可以从两个选择中为此计算创建一个临时表。一旦你将所有信息都放在一张表中，因为你正在做一个简单的选择你的计数，总和会很快。
MySQL 有一个 EXPLAIN 命令，您可以为任何查询添加前缀，例如
EXPLAIN select SUM(SPRICE) AS Tot, MIN(SMIN) AS Min from (SELECT COUNT(LS.SALEPRICE) AS SPRICE, MIN(LS.SALEPRICE) AS SMIN FROM `linkshare` LS WHERE LS.`PRODUCTNAME` LIKE '%DVS Men\'s Comanche Skate Shoe%' UNION SELECT COUNT(CJ.PRICE) AS SPRICE, MIN(CJ.PRICE) AS SMIN FROM `cjfeeds` CJ WHERE CJ.NAME LIKE '%DVS Men\'s Comanche Skate Shoe%' ) AS xyz;
输出对于初学者来说可能有些神秘，请查看有关它的教程以获取更多信息。一般来说：
- 尽可能避免使用“LIKE %blah%”样式的查询，因为 Mark Bannister 建议这些不会使用您创建的任何索引。
- 为选择中使用的任何字段创建索引（在超过一千行的表中）。
- 尽可能保持快速增长的桌子精简
- 尽可能使用固定宽度的列，例如 char/varchar 而不是 TEXT/BLOB
如果您在大型数据集上运行复合慢查询，请考虑对其进行缓存/调整my.cnf 表缓存大小。
总之，总是尝试进行精确的字符串匹配，因为这些可以被索引。您的问题源于规范化不良的表结构。规范化只是意味着（以高级非技术方式）您以一种减少重复的方式组织数据，因此更加一致。好处是它可以更轻松地对其进行有效查询。如果您认为您需要通配符查询，您可能需要将您的产品分类，例如分类为“鞋”等类别，为此，添加一个带有 |category_id, category_name| 模式的 product_categories 表。然后在您的产品表中（如果产品只能在一个类别中）添加一个外键，例如 category_id，在 category_id 字段中添加一个索引，然后通过 category_id 查询产品
例如 select * FROM products where category_id=5
如果您认为需要对数据进行模糊匹配，那听起来确实有点杂乱无章。如果不可避免，请查看您的 devops 人员是否可以设置读取从站，以便您的慢查询不会损害任何重要系统。
