当前位置:首页 > 数据库 > 正文

数据库要怎么用

需求建表结构,规范录入数据,善用查询语句按需提取、统计分析,定期维护优化性能

明确需求与选型策略

业务场景匹配

类型 适用场景 示例应用
关系型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% 立即归档历史冷数据 迁移至对象存储并建立外部表映射

备份恢复演练流程

  1. 全量备份:每周日凌晨执行物理RMAN备份
  2. 增量备份:每日基于二进制日志进行增量同步
  3. 恢复测试:每月模拟灾难场景验证RTO<30分钟目标
  4. 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)实现透明化拆分,保持应用层无

0