尧图网页设计 
1. 连接问题数据库“进不去”的六大真实原因连接不上数据库是“数据库小问题”里最消耗耐心的一类。这里不聊配置文件怎么改而是把我这些年踩过、帮别人排查过的高频场景一次性说清楚。1.1 sqlplus 登录 Oracle 缓慢问题可能根本不在数据库sqlplus 登录 Oracle 出现缓慢或者错误原因非常多。我遇到最典型的一次是应用反馈“每次连数据库要卡十几秒”数据库负载很低监听也正常。排查到最后发现是客户端所在服务器的/etc/hosts里没有配置本机主机名映射。sqlplus 启动时会尝试反解析客户端 IPDNS 超时导致界面卡在那里看起来就像在“等待数据库响应”。后来在 hosts 里加了一行本机映射问题立刻消失。所以遇到 sqlplus 登录慢别急着调数据库参数先按这个顺序排查客户端与服务器之间能否ping通是否有丢包。监听日志里是否有异常断连记录lsnrctl status是否正常。数据库是否有大量会话堆积v$session里处于SNIPED状态的会话是否异常。客户端 DNS 解析是否正常尤其检查hosts文件。很多“数据库变慢了”的问题最后定位都是网络或操作系统层面。数据库管理员要具备这种分层排查的思维不然会在错误的方向上浪费大量时间。1.2 Navicat 连接不上 SQL Server安装成功不等于能用“SQL Server 安装成功了Navicat 连接不了数据库”是热词里很真实的一条。通常有三个原因。第一SQL Server 默认不开 TCP/IP 协议。安装时如果没留意安装完成后协议可能仍处于禁用状态。打开“SQL Server 配置管理器”找到“SQL Server 网络配置”把“Named Pipes”和“TCP/IP”都启用然后重启服务。第二端口不通。SQL Server 默认端口是 1433但很多服务器上有防火墙要么放行端口要么在连接时指定其他端口。Navicat 连接时有个“端口”项很多人默认填 1433实际如果实例是命名实例动态端口可能不是 1433。在 SQL Server 配置管理器里可以看到 TCP/IP 的端口设置。第三身份验证模式。安装时选了“Windows 身份验证模式”后面用sa登录自然失败。这个需要在 SQL Server Management Studio 里把服务器身份验证改为“SQL Server 和 Windows 身份验证模式”然后重启服务。1.3 数据库密码有效期ORA-28000 的锅“怎么查数据库密码有效期是多久”这个问题十有八九是来自 Oracle 或者达梦。Oracle 11g 默认配置了密码生命周期策略默认 180 天。用户密码过期后应用连接直接报 ORA-28000。可以这样查SELECT * FROM dba_profiles WHERE profileDEFAULT AND resource_namePASSWORD_LIFE_TIME;处理方式分两种。一种是临时把某个用户改密ALTER USER username IDENTIFIED BY new_password;另一种是从根本上调整策略比如把有效期限改为无限期ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;我建议生产环境不要一概而论设为无限期。对核心业务系统密码定期更换是安全底线对内部测试库无限期确实省事。具体怎么取舍可以结合企业安全规范来定。1.4 Access 驱动64 位系统的经典陷阱热词里有一条很典型的报错“请先安装 access 数据库 64 位系统驱动程序。64 位引擎不支持 dbc 数据只支持 access 数据”。这种问题多半出现在 Windows 64 位系统上某个旧软件或某个脚本还在用 ODBC 连接 Access。64 位系统上有两套 ODBC 管理器一套在C:\Windows\System32\odbcad32.exe64 位一套在C:\Windows\SysWOW64\odbcad32.exe32 位。如果你安装的是 32 位 Access 驱动但程序是 64 位进程它只认 64 位 ODBC自然找不到驱动。解决方式也不复杂下载并安装 “Microsoft Access Database Engine 2016 Redistributable”注意选择 64 位版本。如果是 32 位程序需要访问 Access则装 32 位引擎并确认连接字符串里使用的驱动名称是Microsoft Access Driver (*.mdb, *.accdb)。两边都装的时候低位数版本必须用/passive参数静默安装否则会报“已有更高版本”的错。这种问题看似“小”但足以让人卡半天。遇到时先搞清楚你的进程是多少位的再决定装哪一套驱动。2. 数据操作增删改查和结构变更里藏着哪些雷增删改查CRUD是数据库最基础的能力但恰恰是这些基础操作往往会因为细节处理不当把表搞出问题来。2.1 MySQL 修改表结构ALTER TABLE 的隐性代价MySQL 的ALTER TABLE在小表上执行很快但在大表上可能让你等到怀疑人生。原因在于早期版本的 MySQL 在修改表结构时会重建整张表期间会对表加元数据锁阻塞写入操作。比如ALTER TABLE user ADD COLUMN nickname VARCHAR(50) DEFAULT ;在 1000 万行数据的表上执行可能要几分钟甚至更久。我的经验是生产环境的表结构变更要讲策略低峰期执行是基本觉悟。用pt-online-schema-change这类工具可以在线变更避免长时间锁表。它的原理是创建一张新表、逐步拷贝数据最后通过触发器同步增量数据。对于只是改默认值、加索引等场景MySQL 8.0 很多操作已经可以秒级完成但容量大的表仍然要谨慎。2.2 MySQL 唯一约束与重复数据先清脏数据再建索引“MySQL 设置唯一已经有重复数据”这个问题很多新人会一头雾水为什么建唯一索引报错因为现有数据里就有重复值。比如用户表里的email字段历史原因导致同一邮箱存在多条记录。此时执行ALTER TABLE user ADD UNIQUE KEY uk_email(email);会报Duplicate entry。正确做法是分三步走先找出重复记录SELECT email, COUNT(*) FROM user GROUP BY email HAVING COUNT(*) 1;保留主键最小的那条记录其他重复记录可以标记或删除视业务逻辑而定。确认没有重复后再建唯一索引。这个顺序不要反。反过来硬建索引报错不说还得回滚徒增麻烦。生产库操作前务必备份这个不用我再强调吧。2.3 Excel 导入数据库编码和字段映射是两大坑Excel 导入数据库是常见的运维需求也是“小问题”聚集地。最典型的两类问题第一是编码问题。Excel 文件另存为 CSV 时默认用的是 ANSI 编码而LOAD DATA导入默认按utf8处理中文直接乱码。解决方式是在语句中指定编码LOAD DATA INFILE /path/file.csv INTO TABLE user CHARACTER SET gbk FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \r\n IGNORE 1 LINES;第二是字段映射问题。Excel 里第一行是列名导入时需要IGNORE 1 LINES跳过或者指定字段列表明确每一列对应表里的哪个字段。否则顺序错一位数据就全错了。2.4 IDEA 导出数据库脚本生成结果要检查用 IDEA 的 Database 工具可以很方便地导出数据库脚本。右键数据库选择Extract相关选项即可。但导出之后别直接扔到生产环境去执行建议检查几点是否包含DROP TABLE语句。默认选项有时会生成删表语句在线上误执行后果很严重。字符集和排序规则是否与目标环境一致。存储过程、触发器的定义是否完整。3. 并发与锁死锁不是偶发事件而是设计问题数据库死锁和并发锁是面试必问、日常必遇、排查起来又比较头疼的内容。3.1 数据库锁的基本认知锁是数据库为了保证并发操作一致性的机制。锁的粒度可以分表级锁、行级锁模式可以分共享锁读锁和排他锁写锁。MySQL InnoDB 默认使用行级锁但不是所有查询都会走行锁条件字段没有索引时InnoDB 会从行锁升级到表锁——这是很多人忽略的。举个例子-- id 有主键索引可以锁行 UPDATE user SET age20 WHERE id1; -- name 没有索引全表扫描时锁范围扩大 UPDATE user SET age20 WHERE name张三;索引缺失导致行锁变表锁是很多“数据库好像越来越慢”问题的真凶。3.2 死锁是怎么产生的又该怎么破死锁的本质是两个或多个事务互相持有对方所需资源又互不相让。最经典的场景是两条UPDATE语句执行顺序不同事务 A先更新id1再更新id2 事务 B先更新id2再更新id1。如果 A 拿到了 1 号锁B 拿到了 2 号锁两边都等对方释放死锁就产生了。遇到死锁我的排查思路是查看 InnoDB 死锁日志SHOW ENGINE INNODB STATUS\G这里会明确打印出死锁涉及的 SQL、持有锁和等待锁的详情。检查加锁顺序。多条UPDATE或INSERT ... ON DUPLICATE KEY操作确保核心业务中事务内语句顺序一致。缩小事务范围。事务不是越长越好长事务占用的锁资源多碰撞概率也大。控制事务隔离级别。可重复读REPEATABLE READ本身就比读已提交READ COMMITTED更容易产生临键锁。如果业务可以接受调整隔离级别能减少锁等待。3.3 数据库连接池大小设置不是越大越好连接池是应用与数据库之间的缓冲层常见的连接池有 HikariCP、Druid、C3P0。连接池的参数配置是热点问题这里给一个比较通用的参考参数建议值说明initialSize5-10启动时预建的连接数maxActive20-50最大连接数视业务并发与数据库性能而定maxWait3000-5000ms获取连接超时时间minIdle5最小空闲连接数连接池不是开得越大越好。很多时候数据库瓶颈不在连接数而在于每条 SQL 的效率和磁盘 IO。连接池开得过大反而容易拖垮数据库出现大量too many connections误报。3.4 数据库同步工具选型看三点涉及到数据库同步市场上工具很多DataX、Canal、Debezium、Maxwell以及各种商业同步软件。选型时我主要看三点第一同步方向是单向还是双向。单向同步选型门槛低DataX 就能解决批量同步问题实时同步则要上 Canal 这类基于 binlog 的工具。第二是否需要全量加增量。全量同步好做增量同步难。Canal 原理是把自己伪装成 MySQL 从库读取 binlog 解析成 JSON 事件再投递到目标端。这套方案在生产环境验证了很多年比较可靠。第三目标库类型。如果源库是 Oracle目标库是 PostgreSQL从字段类型到 SQL 方言都不同需要做数据映射。4. 数据库工具与生态好工具能省一半时间“数据库——小问题”里很大一部分问题其实不是数据库本身的问题而是工具没选对、没用熟的问题。4.1 小体积数据库的福音SQLite 管理工具SQLite 是轻量级数据库的典型代表很多桌面软件、移动应用都在用它。但很多文档并不告诉你怎么管理 SQLite 文件。热词里“sqllite 数据库用哪个管理打开”是高频提问。如果你只是要快速查看.db或.sqlite文件我推荐DB Browser for SQLite。这是一个开源免费的图形化管理工具支持打开、浏览、编辑 SQLite 数据表也支持执行 SQL。日常处理脚本生成的库文件完全够用。如果手头有.dbx文件热词里提到有“dbx 数据库工具”用于管理和转换这类文件。DBX 文件在实际场景中多为某些业务系统的私有格式通用数据库工具打不开需要对应的专用工具来处理。遇到这种文件先确认它的格式来源不要强行用 SQLite 打开避免文件损坏。4.2 微信数据库解密是什么原理热词里出现了“微信数据库解密”。这里要说明一下原理不涉及具体破解方法微信的本地存储使用了 SQLCipher 加密其数据库文件是标准 SQLite 格式但每个页都做了加密。要正常读取需要在连接时提供正确的加密密钥并在打开数据库时指定加密算法。这类问题通常出现在取证、数据恢复等合法场景。如果要用程序方式读取这类加密库应该遵循相关法律法规在授权范围内进行。普通用户想备份微信数据走官方聊天记录迁移功能最稳妥。4.3 数据库管理工具选型图形化之外还要看功能热词里的“数据库同步软件”“托管数据库服务”都属于数据库周边生态。图形化管理工具方面Navicat 和 DBeaver 是两个派系的代表取舍如下Navicat 价格高但用户体验好支持连接 MySQL、PostgreSQL、Oracle、SQL Server、SQLite 等常见数据库但跨平台版本对 Linux 支持不太完整。DBeaver 开源免费基于 Eclipse支持 JDBC 连接几乎所有数据库插件机制灵活。缺点是一些操作耗内存体验稍重。连接上托管数据库服务时要注意云厂商通常不允许直接使用root权限而是提供一个高权限管理账号。这意味着部分系统级别操作如修改my.cnf、重启实例不可用只能通过云控制台或参数组来调整。5. 选型与架构别等数据量大了再后悔数据库选型是个看似自由、实则受限很大的决策。热词中出现了多类数据库——从 MySQL、Redis、SQLite 到时序数据库 TDengine从国产数据库到达梦、人大金仓还有文档型 MongoDB。选错库是最大的“小问题”因为它一旦上线就很难翻身。5.1 MySQL 的日常与边界MySQL 是互联网行业的标配入门门槛低、资料丰富。日常用起来有几个小习惯值得坚持所有表都建主键并尽量用自增 ID 或有序 UUID。字符集统一用utf8mb4避免 emoji 表情写入时报错。每张表都要评估索引避免使用SELECT *这种无差别扫描。但是 MySQL 的边界也很明显单表数据量过亿后写放大和索引膨胀问题会逐步显现复杂地理空间查询、全文检索也不是它的强项。所以遇到“什么都往里塞”的诉求要有说“不”的勇气。5.2 时序数据库的典型选择TDengine 与 C 写入热词里非常具体地提到了“TDengine, c 绑定写入数据库, taos_stmt_prepare”。这组关键词直接指向物联网场景下的时序数据写入。TDengine 是一款大数据时序数据库存储引擎针对时间序列做了大量优化比如列式存储、自动分区、数据级压缩。用 C 绑定时正确的写入步骤是建立连接创建数据库和稳定表STable。使用参数化接口taos_stmt_prepare预编译 SQL。用taos_stmt_bind_param绑定参数。循环写入时复用同一个 stmt避免反复解析 SQL 的开销。结束后调用taos_stmt_close释放资源。很多人在 TDengine 写入慢时总怀疑数据库性能不行实际上问题往往出在没走参数化接口每条记录都重新拼接 SQL 字符串解析效率自然低。绑定参数的方式能显著提升写入吞吐。5.3 国产数据库的真实体验达梦与人大金仓国产数据库在政务、金融等场景应用越来越广。达梦数据库的 SQL 语法与 Oracle 兼容性比较好项目从 Oracle 迁过去会比较顺。人大金仓KingbaseES基于 PostgreSQL 内核同理对 PG 的兼容性很好。选型之前可以先跑一遍兼容性测试脚本重点验证数据库函数、分页语法、字符串处理这些常见差异点。很多看起来“小”的地方——比如日期格式化函数、空字符串与 NULL 的区别——恰恰是迁移时的拦路虎。还有一条热词是“大梦数据库安装”应该是输入法打错字指的就是达梦数据库安装。达梦安装过程中最常遇到的问题有两个一是操作系统不支持官方要求特定的 Linux 发行版版本例如基于内核版本的校验二是字符集和大小写敏感设置安装完成后很难修改建议提前规划。新装的实例默认大小写不敏感但部分应用 SQL 里用了双引号会导致大小写行为不一致。5.4 MongoDB 的核心概念与真实用法热词里明确提到“简述 mongodb 的核心概念: 数据库、集合、文档”。这是入门 MongoDB 必须要回答的三层模型文档DocumentMongoDB 的基本数据单元本质是 BSON 格式类似 JSON 对象字段类型可以动态变化。集合Collection文档的容器。集合相当于关系型数据库的表但它不强制 schema 统一同一个集合里可以有不同的字段。数据库Database集合的集合。一个 MongoDB 实例里可以同时存在多个数据库相互隔离。MongoDB 的优势是快速开发、灵活的数据模型非常适合日志、内容、配置这类结构多变的数据。但它不适合强事务依赖的业务也不能替代关系型数据库在复杂查询上的能力。不要把 MongoDB 当成“万能型数据库”它有自己的用武之地。6. 数据库综合场景课程设计与面试题里的小套路6.1 课程设计案例从题目到实现的完整思路“数据库课程设计”是很多计算机专业学生必经的一关。最常见的题目是“学生管理系统”“图书管理系统”“在线商城后台”。这类课程设计的核心不在于用什么框架而在于数据库设计是否合理。下面以上述典型系统为例展示设计要点第一步明确实体。学生、课程、成绩图书、借阅记录商品、订单、用户。第二步画出实体关系。学生和课程是多对多需要中间表student_course用户和订单是一对多order表里加user_id外键。第三步设计字段类型。不要所有字段都用VARCHAR(255)。比如年龄用INT出生日期用DATE手机号用VARCHAR(20)性别用TINYINT或CHAR(1)。第四步写建表 SQL加上主键、外键和必要的索引。第五步写 CRUD 接口用 JDBC 或 MyBatis 连接数据库。遇到课程设计卡壳的先检查是否没有按实体关系来设计表。很多时候是“单表打天下”导致后续查询全都写不顺手越改越乱。6.2 数据库面试题背后的考察点数据库面试题看似在问记忆实际上在考原理。最常被问到的高频问题事务的四大特性ACID。回答时别只说定义要能举例说明原子性和一致性、隔离性和持久性分别解决什么问题。索引底层为什么用 B Tree。关键点是磁盘随机 IO 少、叶子节点链表便于范围查询。慢查询优化。套路是先看 EXPLAIN再看是否走索引最后考虑改写 SQL。左连接、右连接、内连接区别。出一道 SQL 让面试者当场写答案是最常见的考法。分库分表。主要围绕单表数据量过大后的扩展方案涉及水平拆分、垂直拆分、分片键选择。三大范式。第一范式要求字段原子性第二范式要求消除部分依赖第三范式要求消除传递依赖。6.3 数据库热词里的“周边陷阱”最后我想说说热词里出现的一些容易被忽略的“小问题”“alk studio 数据库下载”“kstudio 数据库下载”这类工具名称输入经常有错字搜索时要灵活变通。“emcc 添加数据库”涉及的是 Emscripten WebAssembly 环境下操作数据库的配置本质是资源文件路径的挂载小问题但容易踩坑。“北风数据库”这是微软经典的 Northwind 示例数据库很多教程用它做演示。遇到版本兼容问题优先考虑用新版示例库替代。“altium designer 中怎样建立本地元器件数据库”这属于特定软件的数据库集成功能需要理解该软件是通过 ODBC 连接外部数据库来管理元器件的。配置时先装驱动、再测连接顺序不能反。7. 一些心得这些年大大小小的数据库问题处理下来我最大的感受是大部分所谓的“小问题”都不是数据库本身的问题而是工具选择、环境配置、使用习惯的问题。数据库是一个成熟的基础软件它的行为大多有规律可寻。遇到报错别第一时间怀疑数据库有 bug先检查自己的连接方式、网络环境、字符编码和权限配置“主语找对”了问题就解决了一半。再分享一个我自己的小习惯每次解决一个问题就在本地建一个笔记文件把报错信息、排查步骤、最终方案记下来。半年之后你会发现很多问题都是重复出现的有了一份自己的“报错字典”后面处理类似问题的速度会快很多。数据库的学习和使用不是一蹴而就的事它需要的是不断地踩坑、记录、复盘然后把经验固化下来。 数据库常见问题全解析：从连接故障到并发锁的排查指南
1. 连接问题数据库“进不去”的六大真实原因连接不上数据库是“数据库小问题”里最消耗耐心的一类。这里不聊配置文件怎么改而是把我这些年踩过、帮别人排查过的高频场景一次性说清楚。1.1 sqlplus 登录 Oracle 缓慢问题可能根本不在数据库sqlplus 登录 Oracle 出现缓慢或者错误原因非常多。我遇到最典型的一次是应用反馈“每次连数据库要卡十几秒”数据库负载很低监听也正常。排查到最后发现是客户端所在服务器的/etc/hosts里没有配置本机主机名映射。sqlplus 启动时会尝试反解析客户端 IPDNS 超时导致界面卡在那里看起来就像在“等待数据库响应”。后来在 hosts 里加了一行本机映射问题立刻消失。所以遇到 sqlplus 登录慢别急着调数据库参数先按这个顺序排查客户端与服务器之间能否ping通是否有丢包。监听日志里是否有异常断连记录lsnrctl status是否正常。数据库是否有大量会话堆积v$session里处于SNIPED状态的会话是否异常。客户端 DNS 解析是否正常尤其检查hosts文件。很多“数据库变慢了”的问题最后定位都是网络或操作系统层面。数据库管理员要具备这种分层排查的思维不然会在错误的方向上浪费大量时间。1.2 Navicat 连接不上 SQL Server安装成功不等于能用“SQL Server 安装成功了Navicat 连接不了数据库”是热词里很真实的一条。通常有三个原因。第一SQL Server 默认不开 TCP/IP 协议。安装时如果没留意安装完成后协议可能仍处于禁用状态。打开“SQL Server 配置管理器”找到“SQL Server 网络配置”把“Named Pipes”和“TCP/IP”都启用然后重启服务。第二端口不通。SQL Server 默认端口是 1433但很多服务器上有防火墙要么放行端口要么在连接时指定其他端口。Navicat 连接时有个“端口”项很多人默认填 1433实际如果实例是命名实例动态端口可能不是 1433。在 SQL Server 配置管理器里可以看到 TCP/IP 的端口设置。第三身份验证模式。安装时选了“Windows 身份验证模式”后面用sa登录自然失败。这个需要在 SQL Server Management Studio 里把服务器身份验证改为“SQL Server 和 Windows 身份验证模式”然后重启服务。1.3 数据库密码有效期ORA-28000 的锅“怎么查数据库密码有效期是多久”这个问题十有八九是来自 Oracle 或者达梦。Oracle 11g 默认配置了密码生命周期策略默认 180 天。用户密码过期后应用连接直接报 ORA-28000。可以这样查SELECT * FROM dba_profiles WHERE profileDEFAULT AND resource_namePASSWORD_LIFE_TIME;处理方式分两种。一种是临时把某个用户改密ALTER USER username IDENTIFIED BY new_password;另一种是从根本上调整策略比如把有效期限改为无限期ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;我建议生产环境不要一概而论设为无限期。对核心业务系统密码定期更换是安全底线对内部测试库无限期确实省事。具体怎么取舍可以结合企业安全规范来定。1.4 Access 驱动64 位系统的经典陷阱热词里有一条很典型的报错“请先安装 access 数据库 64 位系统驱动程序。64 位引擎不支持 dbc 数据只支持 access 数据”。这种问题多半出现在 Windows 64 位系统上某个旧软件或某个脚本还在用 ODBC 连接 Access。64 位系统上有两套 ODBC 管理器一套在C:\Windows\System32\odbcad32.exe64 位一套在C:\Windows\SysWOW64\odbcad32.exe32 位。如果你安装的是 32 位 Access 驱动但程序是 64 位进程它只认 64 位 ODBC自然找不到驱动。解决方式也不复杂下载并安装 “Microsoft Access Database Engine 2016 Redistributable”注意选择 64 位版本。如果是 32 位程序需要访问 Access则装 32 位引擎并确认连接字符串里使用的驱动名称是Microsoft Access Driver (*.mdb, *.accdb)。两边都装的时候低位数版本必须用/passive参数静默安装否则会报“已有更高版本”的错。这种问题看似“小”但足以让人卡半天。遇到时先搞清楚你的进程是多少位的再决定装哪一套驱动。2. 数据操作增删改查和结构变更里藏着哪些雷增删改查CRUD是数据库最基础的能力但恰恰是这些基础操作往往会因为细节处理不当把表搞出问题来。2.1 MySQL 修改表结构ALTER TABLE 的隐性代价MySQL 的ALTER TABLE在小表上执行很快但在大表上可能让你等到怀疑人生。原因在于早期版本的 MySQL 在修改表结构时会重建整张表期间会对表加元数据锁阻塞写入操作。比如ALTER TABLE user ADD COLUMN nickname VARCHAR(50) DEFAULT ;在 1000 万行数据的表上执行可能要几分钟甚至更久。我的经验是生产环境的表结构变更要讲策略低峰期执行是基本觉悟。用pt-online-schema-change这类工具可以在线变更避免长时间锁表。它的原理是创建一张新表、逐步拷贝数据最后通过触发器同步增量数据。对于只是改默认值、加索引等场景MySQL 8.0 很多操作已经可以秒级完成但容量大的表仍然要谨慎。2.2 MySQL 唯一约束与重复数据先清脏数据再建索引“MySQL 设置唯一已经有重复数据”这个问题很多新人会一头雾水为什么建唯一索引报错因为现有数据里就有重复值。比如用户表里的email字段历史原因导致同一邮箱存在多条记录。此时执行ALTER TABLE user ADD UNIQUE KEY uk_email(email);会报Duplicate entry。正确做法是分三步走先找出重复记录SELECT email, COUNT(*) FROM user GROUP BY email HAVING COUNT(*) 1;保留主键最小的那条记录其他重复记录可以标记或删除视业务逻辑而定。确认没有重复后再建唯一索引。这个顺序不要反。反过来硬建索引报错不说还得回滚徒增麻烦。生产库操作前务必备份这个不用我再强调吧。2.3 Excel 导入数据库编码和字段映射是两大坑Excel 导入数据库是常见的运维需求也是“小问题”聚集地。最典型的两类问题第一是编码问题。Excel 文件另存为 CSV 时默认用的是 ANSI 编码而LOAD DATA导入默认按utf8处理中文直接乱码。解决方式是在语句中指定编码LOAD DATA INFILE /path/file.csv INTO TABLE user CHARACTER SET gbk FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \r\n IGNORE 1 LINES;第二是字段映射问题。Excel 里第一行是列名导入时需要IGNORE 1 LINES跳过或者指定字段列表明确每一列对应表里的哪个字段。否则顺序错一位数据就全错了。2.4 IDEA 导出数据库脚本生成结果要检查用 IDEA 的 Database 工具可以很方便地导出数据库脚本。右键数据库选择Extract相关选项即可。但导出之后别直接扔到生产环境去执行建议检查几点是否包含DROP TABLE语句。默认选项有时会生成删表语句在线上误执行后果很严重。字符集和排序规则是否与目标环境一致。存储过程、触发器的定义是否完整。3. 并发与锁死锁不是偶发事件而是设计问题数据库死锁和并发锁是面试必问、日常必遇、排查起来又比较头疼的内容。3.1 数据库锁的基本认知锁是数据库为了保证并发操作一致性的机制。锁的粒度可以分表级锁、行级锁模式可以分共享锁读锁和排他锁写锁。MySQL InnoDB 默认使用行级锁但不是所有查询都会走行锁条件字段没有索引时InnoDB 会从行锁升级到表锁——这是很多人忽略的。举个例子-- id 有主键索引可以锁行 UPDATE user SET age20 WHERE id1; -- name 没有索引全表扫描时锁范围扩大 UPDATE user SET age20 WHERE name张三;索引缺失导致行锁变表锁是很多“数据库好像越来越慢”问题的真凶。3.2 死锁是怎么产生的又该怎么破死锁的本质是两个或多个事务互相持有对方所需资源又互不相让。最经典的场景是两条UPDATE语句执行顺序不同事务 A先更新id1再更新id2 事务 B先更新id2再更新id1。如果 A 拿到了 1 号锁B 拿到了 2 号锁两边都等对方释放死锁就产生了。遇到死锁我的排查思路是查看 InnoDB 死锁日志SHOW ENGINE INNODB STATUS\G这里会明确打印出死锁涉及的 SQL、持有锁和等待锁的详情。检查加锁顺序。多条UPDATE或INSERT ... ON DUPLICATE KEY操作确保核心业务中事务内语句顺序一致。缩小事务范围。事务不是越长越好长事务占用的锁资源多碰撞概率也大。控制事务隔离级别。可重复读REPEATABLE READ本身就比读已提交READ COMMITTED更容易产生临键锁。如果业务可以接受调整隔离级别能减少锁等待。3.3 数据库连接池大小设置不是越大越好连接池是应用与数据库之间的缓冲层常见的连接池有 HikariCP、Druid、C3P0。连接池的参数配置是热点问题这里给一个比较通用的参考参数建议值说明initialSize5-10启动时预建的连接数maxActive20-50最大连接数视业务并发与数据库性能而定maxWait3000-5000ms获取连接超时时间minIdle5最小空闲连接数连接池不是开得越大越好。很多时候数据库瓶颈不在连接数而在于每条 SQL 的效率和磁盘 IO。连接池开得过大反而容易拖垮数据库出现大量too many connections误报。3.4 数据库同步工具选型看三点涉及到数据库同步市场上工具很多DataX、Canal、Debezium、Maxwell以及各种商业同步软件。选型时我主要看三点第一同步方向是单向还是双向。单向同步选型门槛低DataX 就能解决批量同步问题实时同步则要上 Canal 这类基于 binlog 的工具。第二是否需要全量加增量。全量同步好做增量同步难。Canal 原理是把自己伪装成 MySQL 从库读取 binlog 解析成 JSON 事件再投递到目标端。这套方案在生产环境验证了很多年比较可靠。第三目标库类型。如果源库是 Oracle目标库是 PostgreSQL从字段类型到 SQL 方言都不同需要做数据映射。4. 数据库工具与生态好工具能省一半时间“数据库——小问题”里很大一部分问题其实不是数据库本身的问题而是工具没选对、没用熟的问题。4.1 小体积数据库的福音SQLite 管理工具SQLite 是轻量级数据库的典型代表很多桌面软件、移动应用都在用它。但很多文档并不告诉你怎么管理 SQLite 文件。热词里“sqllite 数据库用哪个管理打开”是高频提问。如果你只是要快速查看.db或.sqlite文件我推荐DB Browser for SQLite。这是一个开源免费的图形化管理工具支持打开、浏览、编辑 SQLite 数据表也支持执行 SQL。日常处理脚本生成的库文件完全够用。如果手头有.dbx文件热词里提到有“dbx 数据库工具”用于管理和转换这类文件。DBX 文件在实际场景中多为某些业务系统的私有格式通用数据库工具打不开需要对应的专用工具来处理。遇到这种文件先确认它的格式来源不要强行用 SQLite 打开避免文件损坏。4.2 微信数据库解密是什么原理热词里出现了“微信数据库解密”。这里要说明一下原理不涉及具体破解方法微信的本地存储使用了 SQLCipher 加密其数据库文件是标准 SQLite 格式但每个页都做了加密。要正常读取需要在连接时提供正确的加密密钥并在打开数据库时指定加密算法。这类问题通常出现在取证、数据恢复等合法场景。如果要用程序方式读取这类加密库应该遵循相关法律法规在授权范围内进行。普通用户想备份微信数据走官方聊天记录迁移功能最稳妥。4.3 数据库管理工具选型图形化之外还要看功能热词里的“数据库同步软件”“托管数据库服务”都属于数据库周边生态。图形化管理工具方面Navicat 和 DBeaver 是两个派系的代表取舍如下Navicat 价格高但用户体验好支持连接 MySQL、PostgreSQL、Oracle、SQL Server、SQLite 等常见数据库但跨平台版本对 Linux 支持不太完整。DBeaver 开源免费基于 Eclipse支持 JDBC 连接几乎所有数据库插件机制灵活。缺点是一些操作耗内存体验稍重。连接上托管数据库服务时要注意云厂商通常不允许直接使用root权限而是提供一个高权限管理账号。这意味着部分系统级别操作如修改my.cnf、重启实例不可用只能通过云控制台或参数组来调整。5. 选型与架构别等数据量大了再后悔数据库选型是个看似自由、实则受限很大的决策。热词中出现了多类数据库——从 MySQL、Redis、SQLite 到时序数据库 TDengine从国产数据库到达梦、人大金仓还有文档型 MongoDB。选错库是最大的“小问题”因为它一旦上线就很难翻身。5.1 MySQL 的日常与边界MySQL 是互联网行业的标配入门门槛低、资料丰富。日常用起来有几个小习惯值得坚持所有表都建主键并尽量用自增 ID 或有序 UUID。字符集统一用utf8mb4避免 emoji 表情写入时报错。每张表都要评估索引避免使用SELECT *这种无差别扫描。但是 MySQL 的边界也很明显单表数据量过亿后写放大和索引膨胀问题会逐步显现复杂地理空间查询、全文检索也不是它的强项。所以遇到“什么都往里塞”的诉求要有说“不”的勇气。5.2 时序数据库的典型选择TDengine 与 C 写入热词里非常具体地提到了“TDengine, c 绑定写入数据库, taos_stmt_prepare”。这组关键词直接指向物联网场景下的时序数据写入。TDengine 是一款大数据时序数据库存储引擎针对时间序列做了大量优化比如列式存储、自动分区、数据级压缩。用 C 绑定时正确的写入步骤是建立连接创建数据库和稳定表STable。使用参数化接口taos_stmt_prepare预编译 SQL。用taos_stmt_bind_param绑定参数。循环写入时复用同一个 stmt避免反复解析 SQL 的开销。结束后调用taos_stmt_close释放资源。很多人在 TDengine 写入慢时总怀疑数据库性能不行实际上问题往往出在没走参数化接口每条记录都重新拼接 SQL 字符串解析效率自然低。绑定参数的方式能显著提升写入吞吐。5.3 国产数据库的真实体验达梦与人大金仓国产数据库在政务、金融等场景应用越来越广。达梦数据库的 SQL 语法与 Oracle 兼容性比较好项目从 Oracle 迁过去会比较顺。人大金仓KingbaseES基于 PostgreSQL 内核同理对 PG 的兼容性很好。选型之前可以先跑一遍兼容性测试脚本重点验证数据库函数、分页语法、字符串处理这些常见差异点。很多看起来“小”的地方——比如日期格式化函数、空字符串与 NULL 的区别——恰恰是迁移时的拦路虎。还有一条热词是“大梦数据库安装”应该是输入法打错字指的就是达梦数据库安装。达梦安装过程中最常遇到的问题有两个一是操作系统不支持官方要求特定的 Linux 发行版版本例如基于内核版本的校验二是字符集和大小写敏感设置安装完成后很难修改建议提前规划。新装的实例默认大小写不敏感但部分应用 SQL 里用了双引号会导致大小写行为不一致。5.4 MongoDB 的核心概念与真实用法热词里明确提到“简述 mongodb 的核心概念: 数据库、集合、文档”。这是入门 MongoDB 必须要回答的三层模型文档DocumentMongoDB 的基本数据单元本质是 BSON 格式类似 JSON 对象字段类型可以动态变化。集合Collection文档的容器。集合相当于关系型数据库的表但它不强制 schema 统一同一个集合里可以有不同的字段。数据库Database集合的集合。一个 MongoDB 实例里可以同时存在多个数据库相互隔离。MongoDB 的优势是快速开发、灵活的数据模型非常适合日志、内容、配置这类结构多变的数据。但它不适合强事务依赖的业务也不能替代关系型数据库在复杂查询上的能力。不要把 MongoDB 当成“万能型数据库”它有自己的用武之地。6. 数据库综合场景课程设计与面试题里的小套路6.1 课程设计案例从题目到实现的完整思路“数据库课程设计”是很多计算机专业学生必经的一关。最常见的题目是“学生管理系统”“图书管理系统”“在线商城后台”。这类课程设计的核心不在于用什么框架而在于数据库设计是否合理。下面以上述典型系统为例展示设计要点第一步明确实体。学生、课程、成绩图书、借阅记录商品、订单、用户。第二步画出实体关系。学生和课程是多对多需要中间表student_course用户和订单是一对多order表里加user_id外键。第三步设计字段类型。不要所有字段都用VARCHAR(255)。比如年龄用INT出生日期用DATE手机号用VARCHAR(20)性别用TINYINT或CHAR(1)。第四步写建表 SQL加上主键、外键和必要的索引。第五步写 CRUD 接口用 JDBC 或 MyBatis 连接数据库。遇到课程设计卡壳的先检查是否没有按实体关系来设计表。很多时候是“单表打天下”导致后续查询全都写不顺手越改越乱。6.2 数据库面试题背后的考察点数据库面试题看似在问记忆实际上在考原理。最常被问到的高频问题事务的四大特性ACID。回答时别只说定义要能举例说明原子性和一致性、隔离性和持久性分别解决什么问题。索引底层为什么用 B Tree。关键点是磁盘随机 IO 少、叶子节点链表便于范围查询。慢查询优化。套路是先看 EXPLAIN再看是否走索引最后考虑改写 SQL。左连接、右连接、内连接区别。出一道 SQL 让面试者当场写答案是最常见的考法。分库分表。主要围绕单表数据量过大后的扩展方案涉及水平拆分、垂直拆分、分片键选择。三大范式。第一范式要求字段原子性第二范式要求消除部分依赖第三范式要求消除传递依赖。6.3 数据库热词里的“周边陷阱”最后我想说说热词里出现的一些容易被忽略的“小问题”“alk studio 数据库下载”“kstudio 数据库下载”这类工具名称输入经常有错字搜索时要灵活变通。“emcc 添加数据库”涉及的是 Emscripten WebAssembly 环境下操作数据库的配置本质是资源文件路径的挂载小问题但容易踩坑。“北风数据库”这是微软经典的 Northwind 示例数据库很多教程用它做演示。遇到版本兼容问题优先考虑用新版示例库替代。“altium designer 中怎样建立本地元器件数据库”这属于特定软件的数据库集成功能需要理解该软件是通过 ODBC 连接外部数据库来管理元器件的。配置时先装驱动、再测连接顺序不能反。7. 一些心得这些年大大小小的数据库问题处理下来我最大的感受是大部分所谓的“小问题”都不是数据库本身的问题而是工具选择、环境配置、使用习惯的问题。数据库是一个成熟的基础软件它的行为大多有规律可寻。遇到报错别第一时间怀疑数据库有 bug先检查自己的连接方式、网络环境、字符编码和权限配置“主语找对”了问题就解决了一半。再分享一个我自己的小习惯每次解决一个问题就在本地建一个笔记文件把报错信息、排查步骤、最终方案记下来。半年之后你会发现很多问题都是重复出现的有了一份自己的“报错字典”后面处理类似问题的速度会快很多。数据库的学习和使用不是一蹴而就的事它需要的是不断地踩坑、记录、复盘然后把经验固化下来。