上一篇
数据库要怎么用
- 数据库
- 2025-08-01
- 10
需求建表结构,规范录入数据,善用查询语句按需提取、统计分析,定期维护优化性能
明确需求与选型策略
业务场景匹配
类型 | 适用场景 | 示例应用 |
---|---|---|
关系型DB | 结构化交易记录(ACID特性要求高) | 银行转账系统 |
NoSQL文档库 | 半结构化数据/弹性扩展需求 | 用户行为日志分析 |
列式存储 | 大数据聚合查询 | 数据仓库报表生成 |
时序数据库 | IoT传感器监测 | 智能电表数据采集 |
关键决策点:根据读写比例(OLTP/OLAP)、数据一致性级别、并发量选择引擎,例如电商瞬秒场景适合Redis缓存+MySQL主从复制架构。
主流工具对比表
工具 | 优势领域 | 典型部署方式 |
---|---|---|
PostgreSQL | 复杂SQL与JSON支持 | 单机/主从/分布式集群 |
MongoDB | 模式自由&水平扩展 | Sharding分片集群 |
ClickHouse | 超高速OLAP分析 | MPP架构并行计算 |
TiDB | NewSQL混合形态 | HTAP实时分析处理一体化 |
规范化设计与建模技巧
ER图绘制原则
- 第三范式(3NF):消除传递依赖,如将学生信息拆分为
(学号,姓名)
和(学号,课程ID,成绩)
两个表 - 反规范化优化:高频查询路径预连接表,减少JOIN开销(需权衡存储空间)
- 分区策略:按时间范围(Range)、哈希值(Hash)或列表(List)进行物理分割
索引设计方法论
-复合索引最佳实践示例 CREATE INDEX idx_order_userid_createtime ON orders (user_id, create_time DESC);
黄金法则:遵循”最左前缀匹配”原则,优先覆盖等值查询+排序字段组合
️ 陷阱规避:避免在低基数列建单列索引(如性别字段只有男女两种值)
开发阶段实战要点
SQL编写规范
坏味道模式 | 重构方案 | 性能提升幅度 |
---|---|---|
SELECT FROM ... |
显式指定所需列 | 减少I/O传输量 |
N+1问题(循环内单独查询) | 改用JOIN批量获取关联数据 | 降低DB负载90%+ |
全表扫描无索引提示 | 执行计划分析后添加合适索引 | QPS提高数倍 |
事务管理秘籍
// JTA分布式事务控制伪代码 try { userTx.begin(); accountDao.updateBalance(...); orderDao.insertRecord(...); userTx.commit(); } catch (Exception e) { userTx.rollback(); logger.error("事务回滚原因: " + e.getMessage()); }
原子性保障:确保要么全部成功,要么全部失败,杜绝脏读幻读问题
锁机制选择:乐观锁(版本号机制)适用于冲突少的场景;悲观锁(FOR UPDATE)用于高并发更新保护
运维监控体系搭建
核心指标看板配置建议
监控项 | 告警阈值 | 处置方案 |
---|---|---|
CPU利用率 >85% | 触发扩容预案 | 增加只读节点分担读压力 |
慢查询日志增长过快 | PT99>500ms持续5分钟 | 优化索引或重构SQL语句 |
死锁次数突增 | 每分钟超过10次 | 调整事务隔离级别为RC |
磁盘空间剩余<15% | 立即归档历史冷数据 | 迁移至对象存储并建立外部表映射 |
备份恢复演练流程
- 全量备份:每周日凌晨执行物理RMAN备份
- 增量备份:每日基于二进制日志进行增量同步
- 恢复测试:每月模拟灾难场景验证RTO<30分钟目标
- PITR实现:利用Binlog实现任意时间点恢复能力
安全防护纵深防御
访问控制矩阵示例
角色 | 表名 | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|---|
财务审计员 | salary_detail | ||||
客服代表 | customer_info | ||||
开发人员 | ALL |
SQL注入防御清单
- 使用预编译语句(PreparedStatement)
- Web层部署WAF进行正则过滤
- 敏感操作记录审计日志(含IP/UserAgent等信息)
- 禁止动态拼接SQL字符串
性能调优进阶路径
执行计划解读指南
通过EXPLAIN ANALYZE
命令获取可视化执行树:
-> Stream Agg (cost=100.5..200.7 rows=1000 width=20) -> Seq Scan on large_table (actual rows=9876) Filter: (amount > 1000)
优化方向:若出现全表扫描,优先考虑创建覆盖索引;注意嵌套循环连接改为哈希连接的可能性。
硬件资源适配策略
瓶颈类型 | 解决方案 | 预期效果 |
---|---|---|
I/O等待过高 | 更换SSD并启用存储分级 | IOPS提升10倍以上 |
CPU饱和 | 引入读写分离架构 | Master写压力降低70% |
内存不足 | 增大buffer pool大小 | 减少磁盘换页频率 |
相关问答FAQs
Q1: 如果遇到数据库连接池耗尽怎么办?
A: 采用以下组合拳应对:①提升maxPoolSize至CPU核数×2;②启用公平锁防止队列堆积;③优化业务逻辑减少长事务持有连接;④监控interrupted异常进行熔断降级,根本解决需通过压测确定合理连接数上限。
Q2: 如何判断是否需要做分库分表?
A: 当单表数据量超过500万条且满足任一条件即应实施:①单个查询响应时间持续>2秒;②日常运维影响业务可用性;③备份恢复耗时超过可接受范围,推荐使用中间件(如ShardingSphere)实现透明化拆分,保持应用层无