表名加前缀是避免多业务共用MySQL实例时表名冲突的最轻量隔离手段，常见形式有项目缩写、模块标识、业务域；临时表、备份表须用temp_、bak_等语义化前缀；关联字段名须与被引用主键一致，如user_id。
表名加前缀是为了避免跨业务对象冲突
多业务共用一个 MySQL 实例时，不同团队建的 user、order、product 表会直接撞名。MySQL 不支持 schema 级别隔离（除非用 database 分库），所以靠表名前缀是最轻量、最可控的隔离手段。
常见前缀形式包括：
- 项目缩写：upc_user、oms_order
- 模块标识：t_user、t_order（t_ 表示 table）
- 业务域：finance_account、marketing_coupon
不加前缀的后果不是“可能出错”，而是“必然出错”——比如 A 团队删 user 表时，B 团队的用户数据就没了。
前缀选缩写还是全称？看维护成本和可读性平衡
缩写太短（如 u_user）容易歧义，全称太长（如 user_management_system_user）又超 30 字符限制，还难输易错。
推荐做法：
- 优先用**业务线通用缩写**，比如 jd、tb、dd，内部已有共识
- 新项目统一定义 2–4 字缩写，写进 README 或 DB 文档
- 避免单字母前缀（a_user、b_order），后期无法扩展
- 不要用拼音首字母（yy_user），非中文母语同事看不懂
例如：weixin_user 比 wx_user 更明确，且没超长；im_message 比 i_msg 更易维护。
临时表、备份表必须带独立前缀，否则会被误操作
如果只靠时间后缀区分（如 user_20260415），DBA 或自动化脚本极难识别这是备份还是正式表。一旦执行 DROP TABLE user_20260415，灾备就没了。
必须强制使用语义化前缀：
- 临时表：用 temp_ 或 tmp_，如 temp_user_analysis_20260415
- 备份表：用 bak_，如 bak_user_20260415
- 归档表：可用 arc_，如 arc_order_2025
注意：temp_ 和 tmp_ 不要混用，团队内统一一种；bak_ 后缀日期格式固定为 yyyymmdd，不能用 yyyy-mm-dd（含横杠会报语法错误）。
字段名要不要也加前缀？关联字段必须一致
表名前缀解决的是“谁的表”，字段名前缀解决的是“谁的字段”。尤其在 JOIN 多业务表时，id、status、created_at 这类通用字段极易混淆。
建议规则：
- 主键字段统一用 {table}_id，如 user_id、order_id
- 关联外键字段名必须与被引用表主键名完全一致，比如 user_id 在 order 表里也叫 user_id，不能叫 uid 或 creator_id
- 避免无意义缩写：usr_name 不如 user_name，ord_st 不如 order_status
- 所有字段加注释，特别是状态类字段（order_status 注明 0=待支付、1=已发货…）
最容易被忽略的一点：字段名一致性是跨表 JOIN 和后续分库分表迁移的基础。现在省事用 uid，半年后想把 user 表拆出去，字段映射就全乱了。
