烂设计有多坑
新乡卫辉一家化工企业找我们接手维护旧系统，打开数据库一看：一张表87个字段，表名叫t1，日期字段存的是varchar类型，状态值用1到15的数字表示但没注释。排查一个问题要在代码和数据库之间来回翻，一个简单的bug改了两天。
数据库设计不是拍脑袋的事。设计阶段偷的懒，运维阶段加倍还。下面这8条规范是我们团队做了新乡几十个项目后总结的，不是教科书理论，是血泪教训。
规范一：命名要有意义且统一
表名用业务名词，小写加下划线。order_detail、product_category、user_address，一看就知道是干什么的。别用table1、temp、new_table这种名字。
字段名同样要见名知意。created_at比time清楚，mobile_phone比phone1明确。新乡长垣一家起重机械厂的ERP系统，产品表里有name、title、label三个字段，谁都说不清区别，最后花了一周时间才理清楚业务含义。
统一风格：整库用一种命名规则，别混着来。推荐全部小写+下划线，MySQL对大小写敏感度跟操作系统有关，统一小写最安全。
规范二：每张表必须有主键
主键用自增ID还是UUID？多数场景用BIGINT AUTO_INCREMENT就够了。UUID的好处是分布式场景下不冲突，但索引性能比自增ID差15%-20%，因为UUID是随机写入，B+树页分裂频繁。
新乡高新区一个生物医药公司的临床试验系统，用了UUID做主键，数据量到200万条后查询明显变慢。改成自增ID+业务唯一索引后，查询速度恢复到毫秒级。除非你必须做多库合并，否则别为了"以后可能分布式"提前用UUID。
规范三：字段类型能小不小
状态字段用TINYINT不要用INT，1个字节省下来的空间在大表里很可观。金额用DECIMAL(10,2)不要用FLOAT，浮点数有精度问题，算金额的时候会出鬼。
时间字段用DATETIME还是TIMESTAMP？TIMESTAMP只到2038年（虽然新版MySQL已经解决了），存创建时间用DATETIME更稳妥。新乡原阳一家预制菜企业的溯源系统，生产日期存了varchar，后来要按日期范围查询，索引走不上，全表扫描3秒。改成DATETIME加索引后，50毫秒。
varchar长度按实际需要设，别所有字符串字段都设255。varchar(20)存手机号够用，varchar(255)浪费索引空间。
规范四：索引不是越多越好
索引加速查询但拖慢写入。每加一个索引，INSERT/UPDATE/DELETE都要多维护一棵B+树。新乡获嘉一家精细化工企业的ERP，一张表12个索引，写入性能从每秒2000条降到300条。
索引策略：
1. WHERE条件里频繁出现的字段加索引。
2. 联合索引按区分度从高到低排列。比如(user_id, status)而不是(status, user_id)，因为user_id区分度远高于status。
3. EXPLAIN检查执行计划，看有没有走索引。猜不准的时候就跑一下EXPLAIN，别靠感觉。
规范五：适当冗余，减少JOIN
教科书教你第三范式，实际项目里适度冗余能大幅提升性能。订单表里存一份商品名称，不用每次查询都JOIN商品表。新乡辉县一个景区民宿的预订系统，订单详情页要展示房型名称、价格、入住人信息，原来要JOIN 4张表，查询时间180ms。把房型名称冗余到订单表后，JOIN减到2张表，查询时间降到60ms。
冗余的代价是更新时要同步。商品改名了，订单表里的旧名称要不要改？一般不用——订单是历史快照，改名不影响已有订单。但要在设计阶段就想清楚冗余策略，别上线后临时加。
规范六：软删除还是硬删除
软删除就是加is_deleted字段，删除操作改成UPDATE。好处是数据可恢复，坏处是查询都要带WHERE is_deleted=0，容易漏。
我的建议：核心业务数据软删除（订单、用户、支付记录），日志类数据硬删除。新乡牧野区一个商贸市场的商户管理系统，误删了一个商户的所有信息，硬删除找不回来，扯皮了一周。核心表用软删除，出了问题还有得救。
规范七：每个字段加注释
COMMENT不是可选项。状态字段status TINYINT COMMENT '0=待审核 1=已通过 2=已拒绝'，三个月后你还能看懂，接手的人也能看懂。新乡延津面粉厂的进销存系统，200多张表每个字段都有注释，新来的开发半天就能上手查数据。
规范八：大表提前考虑分页方案
LIMIT 100000, 20这种深分页查询极慢，MySQL要先扫描10万条再丢弃。用游标分页（WHERE id > last_id ORDER BY id LIMIT 20）替代OFFSET分页，百万级数据也能毫秒返回。
数据库设计没有银弹，但遵循规范能避开大部分坑。新乡企业做系统，前期多花时间在表结构设计上，比上线后天天救火强得多。