简介这份资源是芋道 ruoyi-vue-pro 企业级快速开发平台的数据库脚本合集面向使用 Spring Boot 与 Vue 前后端分离架构进行中大型系统开发、二次开发及数据库维护的开发者。包内共 34 个文件以 22 个 zip 压缩包与 12 个 sql 脚本为主整体约 143.22MB涵盖 bpm 工作流、crm 客户管理、erp 企业资源、mall 商城、pay 支付、member 会员、ai 智能模块及报表等业务库的建表与初始化脚本并附 quartz 定时任务、go-view 大屏等配套 SQL便于按模块快速搭建数据库结构。已有 1092 人学习下载。借助这些脚本读者可对照理解各业务模块的表结构、字段设计与模块间关联快速完成环境初始化并为系统维护、数据迁移和二次开发提供可靠参考适合需要完整数据库底座的开发者按需取用。1. 拿到一份“最全 SQL”先别急着导它到底补的是哪块拼图很多团队在搭 ruoyi-vue-pro芋道那套 Spring Boot Vue 的后台脚手架时卡住的地方往往不是代码跑不起来而是数据库初始化这一步反复翻车官方仓库里的 SQL 按模块拆得比较细版本迭代又快字段、菜单、字典、定时任务这些初始化数据一旦对不上前端登录进去菜单是空的或者后台报字段不存在。这份“最新最全 SQL”资源本质上就是把多模块、多版本散落的建表与初始化数据收拢成一套可直接执行的脚本集合解决的是“环境搭起来但数据不全”这个高频痛点。它适合正在做二次开发、需要快速拉起完整功能菜单的初中级后端也适合想对照表结构理解芋道模块划分的读者。下面按“先看清结构、再动手导入、最后避坑验证”的顺序拆开讲。2. 拆开 SQL 包看结构模块划分与执行顺序决定成败2.1 芋道多模块的表结构是怎么组织的ruoyi-vue-pro 的数据库设计不是一张大宽表堆出来的而是按业务域拆成若干模块常见的有系统基础用户、角色、菜单、字典、部门、岗位、基础设施文件、日志、代码生成、定时任务、以及可选的业务模块如支付、商城、工作流等。每个模块既有建表语句也有配套的初始化数据菜单权限、字典项、系统参数。这份“最全 SQL”的价值就在于把这些模块的 DDL 和 DML 都收齐了但收齐不等于能乱序执行——模块之间存在外键式依赖比如菜单表要引用系统应用角色菜单关联表要引用角色和菜单字典数据要引用字典类型。执行顺序错了轻则插入失败重则数据半残后面排查起来非常难受。我一般会先不执行而是把脚本按“建表 → 基础数据 → 关联数据 → 业务数据”四层过一遍确认每个文件属于哪一层。常见做法是文件名里带模块前缀和序号比如01_system.sql、02_infra.sql如果没有序号就自己按依赖关系排。下面这段 bash 只是用来快速列出脚本清单和大致内容帮助你在导入前建立全局视图不涉及任何平台操作。# 列出 SQL 目录下所有脚本按文件名排序先看清单再决定执行顺序 ls -1 sql/ | sort # 快速查看每个脚本前 20 行判断是建表还是初始化数据 for f in sql/*.sql; do echo $f head -n 20 $f done逻辑说明第一条命令建立文件清单排序是为了让带序号的文件自然靠前第二条循环打印每个文件头部目的是区分 DDLCREATE TABLE和 DMLINSERT以及识别脚本里是否包含DROP TABLE这类危险语句。参数上没有复杂配置重点是养成“先看后跑”的习惯。如果你用的是 MySQL 8注意脚本里字符集是否统一为utf8mb4排序规则是否和现有库一致否则跨库导入时容易出现中文乱码或比较规则冲突。2.2 执行顺序与库名、字符集的硬约束真正执行时库名、字符集、SQL 模式这三项必须先定死。芋道的表普遍使用utf8mb4和utf8mb4_general_ci部分版本用utf8mb4_unicode_ci如果你的库默认是latin1或者排序规则不一致导入后关联查询可能报“Illegal mix of collations”。另外 MySQL 8 默认开启了ONLY_FULL_GROUP_BY某些初始化脚本里的聚合查询在严格模式下会失败导入阶段虽然不涉及但后续跑业务 SQL 时会暴露。我的习惯是建库时就把字符集和排序规则显式写死避免继承服务器默认值。-- 建库时显式指定字符集与排序规则避免继承服务器默认配置 CREATE DATABASE ruoyi-vue-pro DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; -- 导入前确认当前库的字符集和脚本保持一致 SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME ruoyi-vue-pro;逻辑说明第一条语句把库的字符集和排序规则固定下来utf8mb4保证能存 emoji 和生僻字排序规则要和脚本里的建表语句对齐第二条是导入前的自检如果查出来的排序规则和脚本不一致就先改库再导入别等报错再回头。参数上utf8mb4_general_ci不区分大小写、性能略好适合大多数后台场景如果你的业务对大小写敏感再考虑utf8mb4_bin但要注意和脚本保持一致否则关联字段比较会出问题。执行顺序上我通常按“系统基础 → 基础设施 → 业务模块”推进每个模块内部先 DDL 后 DML。如果脚本里混着DROP TABLE IF EXISTS务必确认这是空库首次导入别在有数据的库上直接跑。下面是一个按顺序执行的示例用source逐文件导入方便定位是哪个文件出错。# 按依赖顺序逐个导入出错时能立刻定位到具体文件 mysql -u root -p ruoyi-vue-pro sql/01_system_ddl.sql mysql -u root -p ruoyi-vue-pro sql/01_system_data.sql mysql -u root -p ruoyi-vue-pro sql/02_infra_ddl.sql mysql -u root -p ruoyi-vue-pro sql/02_infra_data.sql逻辑说明逐文件导入而不是一次性source整个目录是为了在某个文件失败时能精确知道停在哪一步方便回滚或补数据。参数上-u和-p是账号密码库名放在最后如果脚本里有USE语句库名可以省略但显式指定更稳妥。导入完成后别急着启动应用先跑一遍表数量核对确认该有的表都在。3. 导入后的数据校验菜单、字典、定时任务三处最容易缺3.1 用 SQL 自查菜单树和权限关联是否完整导入成功不等于数据完整。芋道的前端菜单是后端动态下发的菜单表、角色菜单关联表、权限标识任何一处缺失登录后都会表现为“菜单空白”或“按钮没权限”。我一般会先查菜单总数和顶级菜单数量再查角色与菜单的关联是否覆盖了管理员角色。下面这几条查询是导入后的固定动作能快速判断数据是不是“看起来全、实际残”。-- 菜单总数与顶级菜单数量顶级菜单一般对应前端一级导航 SELECT COUNT(*) AS total_menu FROM system_menu; SELECT COUNT(*) AS root_menu FROM system_menu WHERE parent_id 0; -- 检查管理员角色是否绑定了菜单没绑定就会出现登录后无菜单 SELECT r.id, r.name, COUNT(rm.menu_id) AS menu_count FROM system_role r LEFT JOIN system_role_menu rm ON rm.role_id r.id GROUP BY r.id, r.name; -- 找出权限标识为空的菜单这类菜单通常无法控制按钮显隐 SELECT id, name, permission FROM system_menu WHERE permission IS NULL OR permission ;逻辑说明第一条确认菜单表有数据且存在顶级节点第二条用左连接统计每个角色绑定的菜单数管理员角色如果menu_count为 0说明关联数据没导进来第三条排查权限标识缺失芋道的按钮权限依赖permission字段为空时前端v-hasPermi指令会失效。参数上没有需要调的重点是看结果是否符合预期顶级菜单一般是个位数管理员菜单数应该接近总数。如果发现关联表为空优先检查初始化脚本里system_role_menu的插入语句是否因为外键或重复主键被跳过。3.2 字典与定时任务数据的完整性检查字典和定时任务是另外两个容易被忽略的初始化数据。字典类型和字典数据是两张表只导了类型没导数据前端下拉框就是空的定时任务表如果没初始化后台“定时任务”页面打开就是一片空白虽然不影响主流程但会让人怀疑脚本是不是没导全。下面这段查询把这两块一起核对。-- 字典类型与字典数据的配对情况data_count 为 0 说明只有类型没有值 SELECT t.id, t.type, COUNT(d.id) AS data_count FROM system_dict_type t LEFT JOIN system_dict_data d ON d.dict_type t.type GROUP BY t.id, t.type ORDER BY data_count ASC; -- 定时任务数量正常初始化后应该有若干条内置任务 SELECT COUNT(*) AS job_count FROM infra_job; -- 检查定时任务的处理类是否为空为空会导致任务执行时报错 SELECT id, name, handler_name FROM infra_job WHERE handler_name IS NULL OR handler_name ;逻辑说明第一条按字典类型统计关联数据条数data_count为 0 的类型就是“空壳字典”需要补数据第二条确认定时任务表有内置记录第三条排查处理类缺失芋道的定时任务靠handler_name反射调用为空时任务触发会直接抛异常。参数上ORDER BY data_count ASC让空壳字典排在最前面方便优先处理。这三条查完基本能判断这份 SQL 是不是“最全”——全不全不看文件大小看关联数据有没有断链。4. 避坑与排查导入 SQL 时最常见的五类翻车4.1 现象导入报“Duplicate entry”主键冲突原因脚本里带了初始化数据而目标库不是空库或者重复执行了同一个数据脚本。芋道的初始化数据大量使用固定主键比如菜单 ID 从 1 开始重复插入必然冲突。解决首次导入前确认库是空的如果是增量补数据先把脚本里的INSERT改成INSERT IGNORE或ON DUPLICATE KEY UPDATE但要注意后者会覆盖已有配置生产库上别这么干。我的习惯是导入前先mysqldump一份空库结构做对照确认没有残留表。4.2 现象中文变成问号或乱码原因库、表、连接三处字符集不一致。常见的是库是utf8mb4但客户端连接默认latin1或者脚本文件本身不是 UTF-8 编码。解决导入时显式指定--default-character-setutf8mb4并确认脚本文件用 UTF-8 保存无 BOM。如果已经导乱了别在原库上修重建库重新导入更干净。4.3 现象应用启动报“Table doesnt exist”原因模块脚本没导全或者执行顺序导致某张表被跳过。芋道的业务模块表名有前缀区分漏导一个模块的 DDL启动时 MyBatis 加载 Mapper 就会报缺表。解决对照应用配置文件里的数据源和 Mapper 扫描路径把涉及的模块表逐个核对用SHOW TABLES导出实际表清单和脚本里的CREATE TABLE语句做差集缺哪张补哪张。4.4 现象登录后菜单空白但数据库里有菜单原因角色菜单关联缺失或者菜单的status字段为禁用状态或者visible为隐藏。解决先查管理员角色的关联菜单数再查菜单的status和visible字段。芋道前端只渲染status0且visible0的菜单初始化数据里如果有测试用的隐藏菜单属于正常现象别误判为导入失败。4.5 现象定时任务执行报“handler not found”原因handler_name对应的 Bean 不存在通常是业务模块没启用或包扫描路径不对。解决先确认handler_name在代码里确实有对应的Component再检查该模块是否在启动类扫描范围内。SQL 层面只能保证数据在Bean 在不在是代码侧的事这两边要对上定时任务才能跑。5. 把 SQL 当活文档用版本比对与增量同步的一个笨办法这份“最全 SQL”除了拿来初始化还有一个容易被低估的用法当版本比对基线。芋道迭代快表结构经常加字段、改索引如果你手上有一份某个版本的完整 SQL后续升级时就可以用结构 diff 快速定位变化而不是靠人肉翻提交记录。我一般会建两个库一个导入旧版 SQL一个导入新版 SQL然后用information_schema做列级比对把差异列出来再决定迁移脚本怎么写。下面这段查询就是比对两个库同名列差异的简化版实际用的时候把库名换成你自己的。-- 比对两个库中同名表的列差异找出新增或删除的字段 SELECT a.TABLE_NAME, a.COLUMN_NAME AS old_col, b.COLUMN_NAME AS new_col, a.COLUMN_TYPE AS old_type, b.COLUMN_TYPE AS new_type FROM information_schema.COLUMNS a LEFT JOIN information_schema.COLUMNS b ON a.TABLE_NAME b.TABLE_NAME AND a.COLUMN_NAME b.COLUMN_NAME AND b.TABLE_SCHEMA ruoyi_new WHERE a.TABLE_SCHEMA ruoyi_old AND b.COLUMN_NAME IS NULL UNION ALL SELECT b.TABLE_NAME, a.COLUMN_NAME AS old_col, b.COLUMN_NAME AS new_col, a.COLUMN_TYPE AS old_type, b.COLUMN_TYPE AS new_type FROM information_schema.COLUMNS b LEFT JOIN information_schema.COLUMNS a ON a.TABLE_NAME b.TABLE_NAME AND a.COLUMN_NAME b.COLUMN_NAME AND a.TABLE_SCHEMA ruoyi_old WHERE b.TABLE_SCHEMA ruoyi_new AND a.COLUMN_NAME IS NULL;逻辑说明前半段以旧库为基准左连新库找出新库里不存在的列即被删除的字段后半段反过来找新增字段。COLUMN_TYPE一起带出来是为了看类型有没有变比如varchar(64)改成varchar(128)这种不报错但可能影响索引长度的变更。参数上两个库名要换成你实际建的比对库TABLE_SCHEMA条件别漏否则会把系统库的列也扫进来。这个办法笨但可靠比对着两个 SQL 文件肉眼 diff 强得多尤其是字段多、表多的时候。除了列比对索引和唯一约束的变化也值得看information_schema.STATISTICS里能查到索引名和列顺序新增唯一索引往往意味着业务上有去重逻辑迁移前要先清理脏数据否则加索引会失败。我踩过一次坑新版给某张关联表加了联合唯一索引旧数据里有重复行直接执行迁移脚本报Duplicate entry最后是先跑去重 SQL 再加索引才过。从那以后我每次拿新版 SQL 做基线都会先把索引差异单独列一张表逐条确认数据是否满足约束再动手迁移。希望这套“先看结构、再按序导入、最后用查询验完整性”的流程能帮你少走几趟重建库的弯路。本文还有配套的精品资源点击获取