数据初始化是MySQL项目启动阶段的关键环节，需通过SQL脚本+版本管理实现可重复初始化，明确区分基础数据与业务数据，预留表结构扩展性，并将敏感值、运行时数据等交由应用层处理。
数据初始化是 MySQL 项目启动阶段的关键环节，它确保系统从一开始就具备可运行的、结构一致的基础数据（如用户角色、配置项、字典表、默认分类等）。设计得好，能减少上线后手动补数据、避免空指针或逻辑异常；设计得随意，则容易导致环境不一致、部署失败或测试不可靠。
明确哪些数据属于“基础数据”
基础数据不是业务过程中产生的数据（比如订单、用户注册记录），而是支撑系统运转的静态或半静态数据。常见类型包括：
- 系统级字典表：如 status_type（状态类型）、gender（性别）、order_status（订单状态）
- 权限与角色：admin、operator、guest 等预置角色及其菜单/接口权限关系
- 默认配置项：如 system_config 表里的 site_name、default_timezone、email_smtp_host
- 核心业务起点数据：如商品类目树的根节点、默认仓库、初始组织架构（总部）
用 SQL 脚本 + 版本管理实现可重复初始化
避免在代码里硬编码 INSERT 或依赖应用启动时自动创建——这不利于多环境同步和回滚。推荐做法是：
- 将初始化 SQL 拆分为多个语义清晰的文件，例如：01-init-dict.sql、02-init-roles.sql、03-init-config.sql
- 每个脚本开头加注释说明作用和适用版本，结尾用 INSERT IGNORE 或 REPLACE INTO 防止重复执行报错
- 配合 Flyway 或 Liquibase 管理脚本执行顺序与历史记录，支持 dev/test/prod 环境一键同步
- 敏感值（如管理员密码）不写死在 SQL 中，改用部署时通过变量注入（例如用 MySQL 的 SET @admin_pwd := '${ADMIN_PWD}'）
设计基础表结构时预留扩展性
基础数据表看似简单，但后期常需增加字段或调整逻辑。建表时注意：
- 主键统一用 BIGINT UNSIGNED AUTO_INCREMENT，避免 INT 溢出或负值干扰
- 必填字段设 DEFAULT 值（如 is_deleted TINYINT DEFAULT 0，sort_order SMALLINT DEFAULT 0），降低初始化负担
- 带层级关系的表（如部门、类目）预留 parent_id 和 path 字段，方便后续做递归查询或前端展示
- 增加 created_by / updated_by 字段并允许为 NULL，初期可不填，后期接入权限系统再启用
区分“初始化”和“首次运行数据”
有些数据虽属基础范畴，但依赖运行时上下文（如当前时间、服务器 IP、生成的密钥），不适合放在纯 SQL 初始化中：
- JWT 密钥、AES 加密盐值 → 放在应用配置或启动脚本中生成并写入数据库
- 首管理员账号 → 可提供独立的初始化命令（如 php artisan init:admin），而非强制塞进 SQL
- 定时任务初始状态 → 由调度模块在第一次启动时检查并插入，避免 SQL 执行时机与服务启动错位
初始化不是一次性动作，而是随项目演进持续维护的过程。把基础数据当作代码一样写注释、做 review、走 CI 检查，才能让 MySQL 项目稳得住、扩得开、接得上。
