明确业务场景再设计字段
表结构不是越全越好，而是要贴合实际使用。比如用户表中，如果业务从不按“籍贯”筛选或统计，就别加 province、city 这类字段；若只存手机号用于登录，用 VARCHAR(11) 足够，不必上 CHAR(20) 浪费空间。时间字段优先选 DATETIME（支持范围广、时区友好），而非 INT 存时间戳——除非你有高并发写入+需要跨语言毫秒级对齐的特殊需求。
合理使用索引，避免“全表扫描”陷阱
索引不是越多越好，而是要覆盖高频查询条件和排序字段。例如订单表常按 user_id + status + created_at 查询，可建联合索引 (user_id, status, created_at)；但若只查 created_at，这个联合索引就用不上。注意：
- WHERE 条件含 !=、LIKE '%abc'、OR 多字段（无统一前导列）时，索引可能失效
- TEXT/BLOB 字段不能直接建普通索引，需指定前缀长度，如 INDEX idx_content (content(255))
- 频繁更新的字段（如计数器、状态流转字段）不宜建索引，会拖慢写入
拆分大字段与冷热数据
把访问频次低、体积大的数据单独建附表，能显著提升主表查询性能。例如文章内容（content TEXT）、商品详情图 JSON、用户隐私信息（身份证、银行卡）等，都建议移到扩展表中，用 article_id 关联。同时，历史订单、日志类数据可按月归档为 orders_202401、orders_202402 等分区表，配合定时任务清理过期数据。
用好约束与默认值，减少 PHP 层校验负担
数据库该干的事，别甩给 PHP。例如：
立即学习“PHP免费学习笔记（深入）”；
- 邮箱字段加 UNIQUE 和 CHECK (email REGEXP '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$')（MySQL 8.0.16+ 支持）
- 状态字段用 TINYINT(1) 或 ENUM('pending','paid','shipped')，并设 DEFAULT 'pending'
- 金额统一用 DECIMAL(10,2)，避免浮点误差；创建时间用 created_at DATETIME DEFAULT CURRENT_TIMESTAMP
这样 PHP 插入时不用反复判断空值、格式、重复，出错也由数据库直接报错，更可靠。
