必须加索引且作为联合索引最左前缀；共享库+共享表为主流方案；用row policy或视图+definer拦截漏写tenant_id；统一用datetime存utc时间；权限链路需全程闭环。
租户ID字段加不加索引？
必须加，而且要作为联合索引的最左前缀。不加索引的 tenant_id 在查询时会全表扫描，尤其当租户数据量增长后，单表几十万行时响应直接卡住。常见错误是只给 tenant_id 加单列索引，但实际业务查询往往带 created_at 或 status，这时应该建 INDEX tenant_id_created_at (tenant_id, created_at) 这类联合索引。
注意：如果使用 UUID 作为 tenant_id，别用 CHAR(36)，改用 BINARY(16) 存储（配合 UUID_TO_BIN()），否则索引体积翻倍、比较变慢。
用共享数据库+共享表，还是共享库+独立表？
绝大多数中小系统选前者（共享库+共享表），运维成本低、备份恢复简单、跨租户统计也方便。后者（每个租户一张表）看似隔离强，但带来严重问题：SHOW TABLES 变慢、INFORMATION_SCHEMA 查询延迟升高、ORM 映射难维护、DDL 变更要循环执行 N 次。
只有极少数场景适合独立表：租户间数据规模差异极大（比如一个租户占 90% 数据）、合规要求物理隔离、或租户可自主定义字段（需配合 JSON/动态列）。此时务必用表名前缀如 tenant_abc123_orders，别用数据库名区分——MySQL 单实例数据库数有默认上限（max_db_per_user），且跨库 JOIN 几乎不可用。
WHERE 条件漏写 tenant_id 怎么拦截？
靠应用层永远不可靠。必须在数据库层设防：
- 用 MySQL 8.0+ 的
ROW POLICY（基于角色的行级安全策略），对敏感表绑定tenant_id = CURRENT_ROLE()类似逻辑 - 或在所有业务 SQL 执行前加中间件层（如 ProxySQL 或自研 JDBC 拦截器），自动重写 SQL，强制注入
AND tenant_id = ? - 禁止直接暴露原始表给应用，一律通过视图访问，视图定义里固化
WHERE tenant_id = @current_tenant，再配合DEFINER权限控制
漏写 tenant_id 的典型错误现象是：测试环境查不到数据（因为没设值）、生产环境查出其他租户数据（隐私泄露），这类 bug 很难被自动化测试覆盖。
时间字段用 DATETIME 还是 TIMESTAMP？
统一用 DATETIME。虽然 TIMESTAMP 节省 1 字节且自动转时区，但它有致命限制：范围仅到 2038 年、依赖系统时区设置、主从时区不一致会导致值错乱。多租户系统往往要长期存档，且租户可能分布在不同时区，应由应用层处理时区转换，数据库只存标准 UTC 时间。
DATETIME 的额外好处是支持微秒精度（DATETIME(6)），对审计日志、事件排序很关键；而 TIMESTAMP 在 MySQL 5.6 中不支持微秒，在 5.7+ 中虽支持但默认不开启。
别忘了给 created_at 和 updated_at 都加 NOT NULL DEFAULT CURRENT_TIMESTAMP 和 ON UPDATE CURRENT_TIMESTAMP，避免应用层漏传时间导致脏数据。
tenant_id 过滤。最容易被忽略的是存储过程、触发器和事件调度器里的硬编码查询，它们常常直接读表，完全不感知租户上下文。
