1. 数据库创建不是一条SQL的事先想清楚这三件事前阵子接了一个老项目的维护数据库是从早期版本一路升级上来的表结构乱到什么程度呢——同一个用户表里有三个不同的自增主键字符集一半utf8一半utf8mb4月份字段有的用VARCHAR、有的用DATE导入导出时候乱码和类型转换错误能把人逼疯。这个项目最初的起点也不过是当年某位同事随手敲了一条CREATE DATABASE。说句实在话数据库创建的这一刻基本就决定了后面半年你是省心还是折腾。所以这篇我打算把“创建数据库”这件事彻底展开。不是只讲那一句SQL而是把从选型、建库、建表、设权限、配事务到后期运维、乃至面试时会怎么被问到全部串起来讲一遍。适合正在学数据库的同学、刚接手项目需要重建库的开发者、以及像我这种天天跟库打交道的后端工程师参考。先说第一个问题建库之前到底要想清楚什么三个字——选型、字符集、引擎。这三点如果拍脑袋定了后面返工的成本远比你想象的高。1.1 数据库选型不是哪个火选哪个现在市面上的数据库太多了MySQL、PostgreSQL、SQLite、达梦、人大金仓、TDengine、Oracle……很多人选型的时候只看“哪个用的人多”这个思路不太对。我个人的判断维度是这四条数据模型关系型还是时序型还是文档型。你存的是用户订单、财务流水那基本就是关系型如果是设备传感器上报的海量时序数据TDengine这类专用时序库在写入和聚合查询上比MySQL强一个量级。部署环境是自建服务器、内网离线环境还是上云托管。国内信创环境经常要选达梦或人大金仓这类国产数据库它们的语法整体兼容Oracle或PostgreSQL但细节差异非常多。团队技术栈你们团队最熟什么这看着像废话但实际上很多项目死在“选了最强但没人会运维的库”上。规模预期峰值QPS、单表数据量、是否需要分布式。先用SQLite起步的项目和一开始就预期千万级用户的项目选型完全不同。打个具体的比方内部工具型项目用户量几百人数据量百万量级SQLite一个单文件库就够了轻量、零运维根本没必要上MySQL而一个面向C端用户、预期在线用户数上万的产品就得认真考虑MySQL或PostgreSQL并且把读写分离、分库分表这些提前纳入架构设计里。1.2 字符集和排序规则乱码和排序错误的源头这个坑我年轻时踩过而且踩得很痛。早期数据库用了utf8结果用户昵称里一旦出现emoji表情写入就报错后来排查了一圈才意识到utf8在MySQL里只是utf8mb3最多存3字节而emoji需要4字节必须用utf8mb4。所以现在凡是用MySQL建库我基本无脑选utf8mb4排序规则用utf8mb4_unicode_ci或utf8mb4_0900_ai_ciMySQL 8.0默认。这两者的区别在于_0900_ai_ci基于Unicode 9.0标准排序和比较规则更完善支持大小写不敏感的口音匹配_unicode_ci相对保守兼容性更好。除非你有精确排序需求比如原始UTF-8字节序排序否则默认就够用。排序规则不只是“看起来对不对”的问题它直接决定索引的排序方式、WHERE name abc和WHERE name ABC是否会命中、以及范围查询BETWEEN的行为。同一个字符集下换了排序规则索引失效或者查询结果集变化都是可能发生的。1.3 存储引擎InnoDB还是MyISAM还是别的MySQL里默认引擎早已从MyISAM变成了InnoDB这本身就是一个信号。InnoDB支持事务、行级锁、崩溃恢复MyISAM只有表级锁、不支持事务断电后修复全靠修表。2010年以前很多老教程还在教MyISAM因为它的查询性能在特定场景下确实更快但代价是并发写入时整表锁死以及一旦崩溃数据一致性毫无保障。所以我的态度很直接没有特殊理由一律InnoDB。全文索引和空间数据这些原来MyISAM的优势InnoDB现在也覆盖了没什么好纠结的。2. MySQL实战完整建库建表SQL与参数取舍这一节我用生产环境中一份用户订单库的建库过程来演示。环境是MySQL 8.4.11 LTS这是目前比较稳的LTS版本下载解压配置的过程网上有大把教程我不重复重点看SQL本身。2.1 第一步CREATE DATABASE的正确姿势-- 标准建库语句 CREATE DATABASE IF NOT EXISTS shop_order DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_0900_ai_ci DEFAULT ENCRYPTIONN;这四条参数得解释一下IF NOT EXISTS防止重复执行时报错建库脚本一般都要加上确保幂等。DEFAULT CHARACTER SET utf8mb4库级别默认字符集会影响后续未显式指定字符集的表和字段。表级和字段级的字符集可以覆盖库级所以建库这里定好基准非常重要。DEFAULT COLLATE utf8mb4_0900_ai_ci排序规则前面说过了。DEFAULT ENCRYPTIONNMySQL 8.0引入的透明表空间加密开关。涉及敏感数据身份证、手机号的表建议开Y但会带来轻微性能损耗所以库级别默认N具体表按需开。这里有个很实用的操作建完库顺手把库的默认字符集查一遍确认没被全局配置干扰。SHOW CREATE DATABASE shop_order;如果输出和你的预期不一致大概率是my.cnf里character_set_server设置和你的建库语句冲突了。此时以表内实际SHOW CREATE TABLE输出为准。2.2 创建业务账号不要裸奔root很多新手图省事直接用root跑业务。这个习惯极其危险——root一旦密码泄露攻击者拥有全部权限而且如果哪天误操作删了系统表哭都来不及。我在生产环境从不用root连业务库而是为每个业务系统建独立账号只授予该库权限。CREATE USER order_service192.168.10.% IDENTIFIED BY StrongPass_2025; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, REFERENCES ON shop_order.* TO order_service192.168.10.%; FLUSH PRIVILEGES;几个要点主机部分我写的是192.168.10.%意思是只允许这个网段的应用服务器连接数据库不要把%所有主机交给一个业务账号尤其是生产环境。权限列表不给DROP、不给FILE、不给SUPER。DROP权限给了业务账号等于允许应用层把表删了。当然这不是铁律有些内部工具确实需要但最小权限原则必须守住。密码用强密码别用123456这种。MySQL 8.4默认装了validate_password组件弱密码会直接报错这其实是好事。2.3 核心表拆解CREATE TABLE的细节决定成败订单表是这类系统里最核心的表之一我把建表SQL贴出来逐段讲。CREATE TABLE t_order ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, order_no VARCHAR(64) NOT NULL COMMENT 业务订单号, user_id BIGINT UNSIGNED NOT NULL COMMENT 用户ID, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态:0待支付,1已支付,2已发货,3已完成,4已取消, total_amount DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT 订单总金额, pay_amount DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT 实付金额, currency CHAR(3) NOT NULL DEFAULT CNY COMMENT 币种, remark VARCHAR(255) NULL COMMENT 备注, created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) COMMENT 创建时间, updated_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id_created (user_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_0900_ai_ci COMMENT订单主表;逐项说主键BIGINT UNSIGNED AUTO_INCREMENT是MySQL最稳妥的自增主键方案。主键必须是单调递增的这样InnoDB的聚簇索引插入时永远在最右侧追加不会引发页分裂。如果你用UUID当主键随机性会导致频繁页分裂和索引碎片大表上性能影响非常明显。当然分布式场景下用雪花ID也没问题但雪花ID最好也设计成有序的或者在插入层做排序。order_no加了唯一索引。业务订单号天然应该唯一这个约束放在数据库层是兜底防止代码层并发时重复生成。status用TINYINT存状态码注释里写清楚含义。不要用VARCHAR存中文状态排序和统计都不方便。金额用DECIMAL(12,2)绝不用FLOAT/DOUBLE。浮点数是近似值账务数据一旦出现分差就是事故。DATETIME(3)带毫秒精度。原来很多老表用TIMESTAMP它有一个著名的2038年问题——只支持到2038年。8.0之前的TIMESTAMP还有时区转换行为容易造成时间错乱。DATETIME不会有这些烦恼。ON UPDATE CURRENT_TIMESTAMP(3)每次行更新时自动刷新该字段省得应用层手动维护。如果你想在前期避免后续修改表结构的麻烦可以在建表时就加上KEY idx_status之类查询频繁的字段。但索引不是越多越好每个索引都占用空间、拖慢写入后面第四章会细讲。2.4 建库脚本的工程化从SQL片段到可维护的版本化脚本直接在生产库上手动敲SQL是灾难的开始。我现在所有项目的建库脚本都走版本化管理SQL文件放在Git仓库里命名带版本号比如V1.0__init_schema.sql、V1.1__add_user_index.sql配合Flyway或Liquibase这类迁移工具自动执行。好处有三点环境一致测试、预发、生产执行的脚本绝对是同一套。可回溯哪天线上环境数据异常能查到这个表结构是哪个版本改的。可评审每次表结构变更都走一次Code Review字段命名是否合理、索引是否冗余有人把关。用Flyway的配置也很简单Java项目里加上依赖然后在application.yml里指定脚本目录启动时自动按版本号递增执行执行过的脚本会记录在flyway_schema_history表中不会重复执行。3. 账号权限与连接层面的四个必修课数据库创建好了不代表能直接跑业务。实际生产里我在连接层吃过不少亏这里集中说四个高频问题。3.1 最小权限有的放矢才能安全权限这件事我的原则很简单够用就好多一分都不要。后台批量任务需要临时大批量更新时我宁可现授一个临时权限用完后马上回收也不给常驻的宽权限。举个例子报表服务只需要读数据那账号就只给SELECT如果还需要生成临时导出文件可以再加SELECT INTO OUTFILE相关权限但必须在白名单目录下操作。反过来如果哪天发现报表服务跑着跑着报权限不足那大概率不是权限配置的问题而是你需要重新审视这个服务为什么需要写权限——业务设计有问题。3.2 连接池与最大连接数参数不能照抄默认值连接池这块很多文章爱说“默认配置就够用”我不同意。先看一个典型的错误应用侧配了HikariCPmaximum-pool-size填了50数据库侧max_connections还是默认的151服务一上线连接数瞬间打满新请求全排队表现就是“数据库连接超时”。连接池大小的经验公式我不建议死记但可以按这个思路推演假设单接口处理耗时50ms那么一个连接一秒钟最多处理20个请求。如果峰值QPS是2000那理论上只需要100个连接但网络延迟、锁等待都会拖慢单连接吞吐所以通常再加一倍余量。HikariCP这类池子的作者其实一直在强调连接池不是越大越好太大了线程上下文切换开销反而拖垮性能。生产环境我一般从10起步压测后按实际水位调整。HikariConfig config new HikariConfig(); config.setMaximumPoolSize(20); config.setMinimumIdle(5); config.setConnectionTimeout(30000); config.setIdleTimeout(600000); config.setMaxLifetime(1800000); config.setPoolName(order-db-pool);maxLifetime建议小于数据库wait_timeout不然空闲连接被MySQL断开后连接池还在当活连接发请求就会偶发“Connection is not available”的错。3.3 数据库密码有效期到期不能发现的尴尬热搜词里有一条“怎么查数据库密码有效期是多久”这绝对是生产环境的重要问题——很多公司因为密码过期没处理业务半夜告警全挂。MySQL 8.0里可以用default_password_lifetime全局变量控制也支持单账号单独设置-- 查当前全局策略 SHOW VARIABLES LIKE default_password_lifetime; -- 单账号设置永久有效慎用 ALTER USER order_service192.168.10.% IDENTIFIED BY StrongPass_2025 PASSWORD EXPIRE NEVER; -- 单账号设置90天有效 ALTER USER order_service192.168.10.% IDENTIFIED BY StrongPass_2025 PASSWORD EXPIRE INTERVAL 90 DAY;运维侧最好加一个定时巡检脚本每天检查所有账号密码剩余有效期提前一周在工单系统里提醒开发换密。我就是因为建库时没管这个上线后第90天凌晨被数据库的告警砸醒当时应用连接池里全是认证失败的报错——这是最典型的“建库一时爽运维火葬场”场景。3.4 连接超时与time_wait网络层的隐形杀手如果你发现应用偶尔报Communications link failure但是数据库负载并不高大概率是网络层或连接生命周期问题。这里有两类常见坑数据库侧wait_timeout默认8小时应用连接池空闲连接超过这个时间被服务端断开但客户端不知道直到下一次发请求才发现连接已死这种叫“断线重连”。解决方法是连接池的maxLifetime小于服务端wait_timeout前面提过。TCP层的TIME_WAIT堆积。高并发短连接场景下net.ipv4.tcp_tw_reuse没开启会导致大量TIME_WAIT占用本地端口最终表现为无法新建连接。这个偏运维向但如果建库后应用频繁重启你会更容易撞上这个问题。4. 表结构设计的核心细节主键、索引与字段类型建库是外壳表结构是骨架。这一节讲的每一个点都对应着热搜词里的“数据库增删改查”和“数据库面试题”不管是日常开发还是面试都绕不开。4.1 主键策略自增、雪花ID还是业务主键自增主键最简单写入性能最好但在做分库分表或数据迁移时会遇到全局ID冲突需要改造成auto_increment_offset错位或换分布式ID方案。雪花ID全局唯一、趋势递增适合分布式系统。但要注意雪花ID是19位数字用BIGINT存储没问题但如果你用VARCHAR存索引空间直接翻倍查询性能也打折。而且应用层必须保证算法正确时钟回拨会生成重复ID这个问题网上讨论很多实现时要加时钟回拨保护。业务主键比如身份证号、订单号直接当主键方便查询但一旦业务规则变化比如身份证号允许更新就非常被动。我的建议是始终保留一个无业务含义的代理主键id业务唯一性用唯一索引来约束。4.2 索引设计先看查询再建索引索引设计的第一原则索引不是越多越好而是越贴合查询越好。我见过一张表十几个索引每次写入要维护十几棵B树插入性能惨不忍睹而真正高频的查询反而没有覆盖索引。正经做法是先收集业务里所有高频查询SQL用EXPLAIN看执行计划再决定索引。EXPLAIN SELECT order_no, total_amount FROM t_order WHERE user_id 123 AND status 1;user_id和status都有过滤条件但选择性哪个更高user_id几乎每个值只对应少量行status只有0-4五种取值。所以组合索引应该建在(user_id, status)上把高选择性字段放前面。少数字段如status单独建索引基本没意义优化器会认为扫描全表更快而放弃它。另外强烈建议多利用覆盖索引如果查询只需要order_no和total_amount那么建一个包含这两个字段的索引InnoDB可以直接从索引树上取数不用回表这个性能差距在大数据量扫描时非常明显。4.3 字段类型选错后果有多严重手机号用VARCHAR(11)存没问题但千万别存成BIGINT前导0会丢失也别用VARCHAR(255)那是给长文本留的空间索引效率也会下降。字段长度精确到业务真正常态值手机号就11别给255。日期时间用DATETIME不要用字符串。用字符串存日期会让范围查询退化成逐个字符比较而且一旦格式不统一2025-01-02和2025/1/2排序则彻底乱掉。布尔值用TINYINT(1)或BOOLEAN不要用VARCHAR存“是/否”。用数值便于统计和索引。大文本文章正文、JSON配置用TEXT或JSON类型。MySQL 8.0的JSON类型支持JSON函数查询还能建虚拟列索引用起来比存VARCHAR方便得多。5. 事务隔离级别与并发场景下的坑建好表之后并发一上来事务和锁的问题就浮现了。热搜词里“数据库死锁”“数据库并发锁”都属于这个范畴。5.1 四种隔离级别分别适合什么场景先从理论上过一遍这四种隔离级别在面试里被问到烂但还是值得实操验证而不只是背定义隔离级别脏读不可重复读幻读实现方式READ UNCOMMITTED可能可能可能读不加锁READ COMMITTED不可能可能可能读快照每次语句新快照REPEATABLE READ不可能不可能可能InnoDB下基本可避免事务开始建快照 间隙锁SERIALIZABLE不可能不可能不可能全表加锁MySQL InnoDB默认是REPEATABLE READ它通过快照读间隙锁Gap Lock解决了大部分幻读问题但要注意间隙锁也是死锁的主要来源之一。如果你业务对幻读完全可以容忍比如只做APP端的榜单读取用READ COMMITTED会减少锁冲突并发更好。PostgreSQL默认是READ COMMITTED这也是很多从PG转MySQL的人觉得MySQL“更容易锁”的原因之一。实操层面怎么改隔离级别-- 会话级别 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 全局配置需要重启前写入my.cnf transaction-isolation READ-COMMITTED5.2 死锁是怎么发生的怎么排查死锁的经典场景两个事务都先更新表A再更新表B但顺序相反。事务1锁住了A行、事务2锁住了B行然后两边都在等对方释放——死锁形成。InnoDB检测到死锁会直接回滚其中一个事务报错信息长这样ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction排查方法先看最近一次死锁日志SHOW ENGINE INNODB STATUS;重点读LATEST DETECTED DEADLOCK段落它会列出两个事务各自持有哪些锁、等待哪些锁。我处理过的一次线上死锁最后定位到是两条UPDATE语句的WHERE条件走索引方式不一致一个走uk_order_no一个全表扫导致锁的区间不一致形成交叉等待。修复方式很简单统一两条更新的索引路径并且调整业务逻辑让所有地方都按同一个顺序更新表。预防死锁的几个实操建议多个事务更新多个表时保持一致的加锁顺序。控制事务大小事务越短持锁时间越短死锁概率越低。在RR隔离级别下避免范围更新WHERE updated_at ?跨度太大因为间隙锁锁定范围极广。应用层做好死锁重试机制。死锁无法100%避免但可以优雅降级捕获死锁异常后重试2~3次或者直接返回“系统繁忙”让用户重试。5.3 并发写入时的常见现象天真的乐观锁 vs 悲观的悲观锁这个误区我常遇到听说乐观锁性能好于是所有更新都不加锁只依赖版本号字段。殊不知在高并发抢购、库存扣减这类强一致场景下乐观锁会导致大量更新失败重试反而比锁更慢。而悲观锁用SELECT ... FOR UPDATE虽稳处理不好又会拖长锁周期。实际选型逻辑是读多写少且冲突概率低用乐观锁写多且强一致用悲观锁或队列化写操作。比如扣库存我的做法是原子更新UPDATE t_stock SET stock stock - 1 WHERE sku_id ? AND stock 0;这里不需要锁也不需要版本号靠的是stock 0条件加行锁的原子语义。如果影响行数为0说明库存不足。这就是典型的“数据库层面的并发控制”比在应用里写一堆锁逻辑高效得多。6. 创建后的日常运维与工具链选择数据库创建只是开始后面无穷无尽的运维工作才是重头。这一节讲工具和几个高频运维动作。6.1 工具选择dbx、DB4S、Navicat还是DBeaver界面工具这件事每人都有一套偏好但新手选工具经常踩坑。先看一个对比工具平台核心特点适合场景DBeaver跨平台/开源支持几十种数据库ER图、SQL编辑器、数据导出功能全日常多库管理首选Navicat跨平台/商业界面精致、功能成熟导入导出极其方便公司有预算追求效率DB4S (DB Browser for SQLite)跨平台/开源专门针对SQLite轻量、免安装SQLite单文件库的浏览和编辑dbx特定工具主要面向SQLite数据库文件的管理、加密解密场景特定取证/数据恢复场景命令行 mysql client全平台最可靠支持全部参数SSH到服务器上直连生产环境运维必备我不建议新手一上来就依赖图形界面的“可视化建表”因为那会掩盖你对SQL的理解。最好的学习路径是先用命令行建库建表搞清楚每句SQL在干什么然后再用图形工具提高效率。生产环境的变更我从来只用命令行脚本图形工具只用来查数据和调试SQL。另外一个热搜词“sqlite数据库用哪个管理打开”——SQLite的文件就用DB4S打开或者用VS Code的SQLite插件双击库文件就能浏览表结构非常方便。记住SQLite是单文件数据库分布式和并发写入别指望它。6.2 数据同步与导入导出Excel导入的常见坑业务里经常有“Excel导入数据库”的需求。最省事的方案是先用CREATE TABLE建一张和目标结构一致的临时表字段类型放宽全用VARCHAR或TEXT然后通过Navicat、DBeaver的导入向导把Excel灌进去再用SQL做清洗和转换INSERT INTO t_user (user_name, phone, created_at) SELECT name, phone, STR_TO_DATE(create_date, %Y-%m-%d) FROM tmp_import WHERE phone IS NOT NULL AND phone REGEXP ^1[0-9]{10}$;注意几个坑Excel里的日期经常是“2025/1/2”这种格式直接用字符串灌进日期字段会报错需要先导入临时表再用STR_TO_DATE转换。数字列的精度问题身份证号、长订单号在Excel里会被转成科学计数法导入前必须把Excel列设置为“文本”格式。数据量大的Excel几万行以上用Python的pandassqlalchemy直接批量写入比图形界面导入向导快得多还稳定。批量写SQLite或MySQL的示例import pandas as pd from sqlalchemy import create_engine df pd.read_excel(orders.xlsx, dtype{order_no: str}) engine create_engine(mysqlpymysql://user:passhost:3306/shop_order?charsetutf8mb4) df.to_sql(t_order, engine, if_existsappend, indexFalse, chunksize1000)6.3 定时巡检硬盘、慢查询和容量增长建库之后不能被动等告警。我习惯每个库配套一个巡检脚本至少覆盖三件事容量监控information_schema.tables里按库统计表大小设置容量阈值告警比如超过磁盘80%要提前扩盘或清日志。慢查询分析打开slow_query_log定期把慢日志拉出来看TOP N逐条分析是否缺索引。连接数水位监控Threads_connected和Max_used_connections发现连接数持续在80%以上就要优化连接池或考虑扩容。-- 查看所有库大小 SELECT table_schema, ROUND(SUM(data_length index_length) / 1024 / 1024, 2) AS size_mb FROM information_schema.tables GROUP BY table_schema;还有一个容易被忽略的binlog清理策略。MySQL默认的binlog保留天数在8.0里是30天如果你的磁盘不是特别大建议设短一点比如7天否则过一段时间你会发现磁盘被binlog吃光了这是新手最常见的磁盘满事故源头。7. 面对面试官时如何把“创建数据库”讲出深度最后一个角度比较特别——如果你在准备数据库相关面试你会发现“创建数据库”这种基础问题恰恰是考察深度的切入口。面试官问“请你说说怎么创建一个数据库”看似简单如果你只回答CREATE DATABASE那大概率平平无奇。真正拿到高分的回答通常是这样递进的7.1 从一条SQL到存储引擎与磁盘结构先回答基础语法然后自然引出存储引擎选择。面试官会追问“InnoDB和MyISAM有什么区别”“InnoDB为什么支持崩溃恢复”这时候能回答出redo log、undo log、双写缓冲doublewrite buffer、聚簇索引这些点就说明你不是背的而是真在运维里遇到过掉电、崩溃恢复的场景。我自己的回答句式是“创建数据库时我首先确定的不是SQL而是引擎。InnoDB的redo log保证了提交后即使进程崩溃数据不丢因为提交时日志先落盘undo log配合MVCC实现了多版本并解决了一致性读的问题。MySQL 8.0里MyISAM基本已被淘汰所以默认就是InnoDB。”这一下就把话题从语法拽到了存储引擎原理面试官会立刻在稿纸上画一个加号。7.2 从字符集到乱码定位思路另一个高频追问是“为什么会有乱码”。很多人只背了“客户端、连接、服务端、数据库四方字符集要一致”但一问到怎么排查就卡壳。这里我提供一个能直接实操的排查链路SHOW VARIABLES LIKE character_set%;输出会包含character_set_client、character_set_connection、character_set_results等。乱码的本质是数据在写入和读出时经过了不同的编码转换。比如客户端用utf8mb4发送连接层按latin1解析数据进库时已经是被错误解释过的字节再以utf8mb4存进去就出现了永久性乱码。解决办法是统一客户端连接串JDBC/连接池的characterEncodingutf8mb4。数据库、表、字段统一utf8mb4。排查已有乱码数据时用HEX()看字节确认是不是UTF-8编码被截断。这类问题能答出“字节如何被错误解释”这个层面说明你已经不是停留在配置层面的新手了。7.3 从索引到优化器的取舍逻辑面试里“给了你一张千万级表怎么加索引”也是经典题。单纯的回答“给查询条件加索引”只会被继续追问“那为什么不是所有条件都加索引”。这正是前面第四章内容的价值所在索引的选择性、左前缀原则、覆盖索引、索引下推以及写入放大成本把这些讲清楚整个回答的颗粒度就上来了。我总结的面试要点面试官要的不是死知识点而是你在真实场景里的决策依据。“我当时建了一棵联合索引因为业务查询90%都走user_idcreated_at虽然增加了部分写入开销但查询收益远大于写入代价”——这种回答比背十页八股文有用。7.4 从死锁到系统设计的全局观如果面试官顺着事务继续问“你怎么处理死锁”回答的层次会从单库跳到系统设计。除了前面讲的锁顺序、事务大小之外更高级的回答是在系统设计阶段就规避死锁。比如用消息队列削峰把并发写请求串行化比如用分库分表把竞争锁的粒度拆小再比如热点账户扣减用批量合并的方式减少事务数量。这些都属于“创建数据库”之后整个数据链路的架构考量。能自然把话题延伸到这一层基本就能给面试官留下“这个人不仅会建库还会设计数据系统”的印象。8. 结尾聊聊我这些年建库养成的习惯写了一整篇最后不总结了只分享几个我现在建库时雷打不动的小习惯。第一个习惯每建一个库先建文档。这个文档不用长三五行就够——库是干嘛的、负责人是谁、字符集选了什么、有什么特殊的表结构约定。别笑我踩过太多“这个库谁建的不知道、里面是什么没人知道”的坑了。建库文档比建库SQL更值钱。第二个习惯凡是生产库变更先过备份再过发布。建表、加字段、加索引之前先确认最近的备份存在且可恢复。有人觉得表结构变更不需要备份但一旦一条ALTER TABLE跑挂了你连回滚的基准都没有。我习惯在变更前做一次mysqldump --single-transaction哪怕只是给自己买个安心。第三个习惯永远留一个运维账号永远不交到业务手里。这个账号只做运维操作不在应用配置里出现。遇到紧急情况时它就是你的逃生通道也是审计追踪的锚点。数据库创建这件事听起来基础得不能再基础但恰恰是地基中的地基。一个库的字符集、引擎、权限、索引策略、事务配置决定了它未来是稳稳当当跑三年还是上线后天天让人救火。希望这篇内容能帮你把“创建数据库”这四个字背后的工程量看全从今天起每个新库都建得明明白白。