tenant_id必须作为复合索引最左列，否则索引失效；正确写法为CREATE INDEX idx_orders_tenant_status_created ON orders (tenant_id, status, created_at)；需结合查询模式精简字段数，避免冗余。
tenant_id 必须是复合索引最左列，否则等于没建
如果你在多租户表里建了 CREATE INDEX idx_orders_status_created ON orders (status, created_at)，但查询总带 WHERE tenant_id = ? AND status = 'paid'，那这个索引几乎不会被用到。MySQL 的 B+Tree 索引严格遵循最左前缀匹配，tenant_id 不在最左，优化器就无法跳过其他租户的数据页，只能全表扫描。
真正有效的写法是：
CREATE INDEX idx_orders_tenant_status_created ON orders (tenant_id, status, created_at);
-
tenant_id是高频、高选择性、且从不缺失的等值条件，必须打头 - 后续字段按查询频率和选择性排序：比如
status比created_at更常用于等值过滤，就放前面 - 如果还有
ORDER BY created_at，把created_at放最后能避免文件排序
聚合查询慢？先看 tenant_id 是否在索引里打头
执行 SELECT COUNT(*) FROM orders WHERE tenant_id = 123 AND status = 'shipped' GROUP BY product_id 却跑得慢，大概率不是 GROUP BY 拖累的，而是索引没让 MySQL 快速定位到租户 123 的全部行。
此时哪怕加了 WHERE tenant_id = 123，若索引是 (status, tenant_id) 或 (created_at)，优化器仍可能放弃索引走全表扫描。
- 必须用
(tenant_id, status, product_id)这类以tenant_id开头的复合索引 - 如果
GROUP BY字段也参与过滤（如WHERE tenant_id = ? AND product_id IN (...)），把product_id放第二位可进一步剪枝 - 分区表场景下，
RANGE PARTITION BY tenant_id能替代索引做物理剪枝，但要求查询必须精确命中单个tenant_id
别信视图或存储过程里硬写的 WHERE tenant_id
MySQL 不支持行级安全策略（RLS），所以 CREATE VIEW v_orders AS SELECT * FROM orders WHERE tenant_id = @current_tenant 是危险的——@current_tenant 是会话变量，连接池复用时极易残留旧值，导致查出其他租户数据。
真正可靠的租户隔离只发生在两层：
- 应用层：ORM 拦截所有 SQL，自动注入
AND tenant_id = ?，且对COUNT、DISTINCT、窗口函数等特殊语法做额外校验 - 数据库层：索引强制让带
tenant_id的查询快，不带的查询慢到不可接受（倒逼开发不敢漏）
如果发现某条慢查没带 tenant_id，优先检查是不是 ORM 拦截漏了，而不是急着加索引。
复合索引字段数别贪多，tenant_id + 2～3 个高频字段够用
有人建 (tenant_id, status, type, channel, region, created_at) 这种六字段索引，结果写入变慢、空间暴涨，而实际查询很少同时过滤这么多条件。
更务实的做法是聚焦真实查询模式：
- 查订单列表：常用
tenant_id + status + created_at - 查统计报表：常用
tenant_id + status + product_id - 查用户行为：常用
tenant_id + user_id + event_type
每个核心查询路径配一个精简索引，比堆一个“全能索引”更省资源、更易维护。别忘了定期用 EXPLAIN 验证索引是否真被命中——尤其注意 key_len 和 rows 值是否合理。
最容易被忽略的是：索引生效的前提，是应用代码里每一条 SQL 都老老实实带上 tenant_id 参数。再好的索引，也救不了漏过滤的查询。
