O. Jones's questions

在 MySQL / MariaDB 中，我有一个带有固定长度行的表（没有 VARCHAR、TEXT 等）

CREATE TABLE trigram (
    id BIGINT(20) NOT NULL,
    trigram CHAR(3) NOT NULL COLLATE 'utf8mb4_general_ci',
    PRIMARY KEY (trigram, id) USING BTREE,
    INDEX id (id) USING BTREE
)
COLLATE='utf8mb4_general_ci' ENGINE=InnoDB ROW_FORMAT=COMPACT;

该表有数十兆行，并获取这种形式的生产查询

SELECT id FROM trigram 
 WHERE trigram IN ('dba', 'ba.', 'a.s', '.st', 'sta', 'tac', 'ack')
 GROUP BY ID HAVING COUNT(*) = 7

以及插入和DELETE FROM trigram WHERE id = 12345维护查询。索引适合表的查询模式。

该表是穷人的卦索引。（这个可怜的人无法升级到 postgreSQL 并使用其内置的 trigram 索引，叹息。）示例查询查找id其中包含“dba.stack”字符串的 s。content_column LIKE '%dba.stack%'它比建立三卦表要快得多。

编辑： “更好”是什么意思？更快、更可靠、生产中缓冲池刷新更少、非 DBA 用户的维护负担更少。

问题：我应该使用 ROW_FORMAT=COMPACT 定义这个固定长度行表吗？或者需要 DYNAMIC 吗？我注意到 COMPACT 占用的磁盘空间要少得多。

问题：还有其他建议或需要担心的性能问题吗？

我的用户（WordPress.org 软件用户）大部分使用 MariaDB 10.3+，但也有一些使用 MySQL 8，还有一些使用 MySQL 5.7-。我不需要支持 Antelope 或 MyISAM 遗留的东西。

另一个编辑：

我的IN()查询对表中包含 180K 行的测试数据集进行范围扫描。JOIN答案中建议的 UNION 表执行嵌套循环。范围扫描花费的时间更少。在 MariaDB 10.11、MySQL 8 和 MySQL 5.7 上正确。物有所值。看起来跳过扫描优化效果很好。

如果顺序 AUTO_INCREMENT 列也不是 MySQL 表的主键，它是否必须有自己的 UNIQUE 索引才能确保长期数据完整性？

我正在重新索引一个特定的 MySQL 表以加速某些非常常见的 WHERE 子句。该表来自WordPress CMS。它的发行版外定义，简化，就是这样。

CREATE TABLE wp_postmeta (
    meta_id BIGINT UNSIGNED AUTO_INCREMENT,
    post_id BIGINT UNSIGNED,
    meta_key VARCHAR(255),
    meta_value LONGTEXT,
    PRIMARY KEY (meta_id),
    INDEX post_id (post_id),
    INDEX meta_key (meta_key)
);

MariaDB / MySQL (InnoDB) 现在使用聚集索引，所以我将 PK 更改为：

    PRIMARY KEY (post_id, meta_key, meta_id)

post_id = 42 AND meta_key = 'value'这意味着可以使用聚集索引和 LONGTEXT 获取来满足WHERE 过滤器等。事实证明，它可以解决我的用户的性能问题。

问题是：这个重新索引的表是否还需要在自动递增 ID 列上建立唯一索引才能长期保持正常工作？或者我可以省略该索引以节省一点空间和 UPDATE / INSERT 性能吗？

    UNIQUE INDEX meta_id (meta_id),

（我知道可能有比这个更好的表格设计。但是我目前的任务不允许我更改表格，只能更改索引。）

在生产应用程序（C# 与 SQL Server 2014 Standard 对话）中，有一个如下所示的查询。大多数时候它以毫秒为单位运行。但偶尔（对于某些值@Id），它会发疯并且需要一分钟左右。这比应用程序超时时间长，因此用户的应用程序失败。

在“发疯”的情况下，返回的结果集正确地是空的，因为它在许多但不是所有其他情况下都是空的。

幸运的是，这在生产和开发环境中都是可重现的。

开发人员说从查询中删除“TOP 1”，然后确保应用程序使用结果集中的额外行，从而解决了性能问题。

查询规划TOP 1器在存在时建议不使用索引。（在开发中）。

更改查询和修复应用程序正在进行中。推出需要一段时间。

我的问题：是否有任何 DBA 可访问的方法来调整或调整生产 SQL Server 实例以在应用程序更改与新查询推出之前克服这个问题？

SELECT TOP 1
       subscription_id 
  FROM subscription AS sub
  JOIN billing_info AS bi ON bi.billing_info_id = sub.billing_info_id   
  JOIN person_group AS apg ON apg.person_id = bi.person_id
  JOIN pplan ON pplan.plan_id = sub.plan_id
  JOIN product ON product.product_id = [plan].product_id 
  JOIN product_attribute ON product_attribute.product_id = product.product_id 
 WHERE apg.group_id = @Id
   AND apg.start_date < GETDATE()
   AND (apg.end_date IS NULL OR apg.end_date > GETDATE()) 
   AND (sub.end_date IS NULL OR sub.end_date > GETDATE()) 
   AND product_attribute.attribute_type = 'special feature' 
   AND product_attribute.attribute_data = '1' 
 ORDER BY sub.start_date ASC;