在南京本地企业信息化建设中，数据库往往是最容易被低估的一环。许多团队在系统上线初期只关注功能跑通，等到日活数据积累到几十万条，查询延迟飙升、连接池频繁告警时才开始补救。作为深耕南京本地的技术团队，**南京威客拓信息科技有限公司：企业信息系统开发，IT技术外包，网站定制开发，数字化运维，行业解决方案**，我们在多个交付项目中反复验证了一件事：数据库选型和优化不是运维的事后工作，而是架构设计阶段就必须落子的关键决策。

选型不是比参数，而是匹配业务读写模型

很多团队选数据库时习惯打开 benchmark 榜单横向对比 QPS，但真实业务场景远比压测复杂。我们通常先做一轮读写画像：

• 读多写少、强事务（如订单、账务）→ PostgreSQL 或 MySQL InnoDB，优先保证 ACID；
• 写多读少、时序特征（如设备上报、日志）→ 时序库或 ClickHouse 列存；
• 高并发点查、结构灵活（如会话、缓存层）→ Redis 配合持久化策略。

曾有一个南京本地的设备管理平台，客户坚持用单机 MySQL 扛每秒数千条写入，结果写入抖动严重。我们将其拆分为 MySQL 存业务主数据 + TDengine 存时序指标，写入延迟从 200ms 降到 15ms 以内，这个改造只用了三天。

性能优化：从索引到连接池的实操清单

优化不是堆配置，而是有优先级地排查瓶颈。以下是我们交付中沉淀的 Checklist：

1. 慢查询先行：开启 slow_query_log，阈值设 200ms，先抓出 Top 10 语句再谈其他；
2. 索引覆盖：避免回表，联合索引遵循最左前缀，用 EXPLAIN 确认 type 至少到 range；
3. 连接池调优：HikariCP 的 maximumPoolSize 不是越大越好，一般按 CPU 核数 × 2 + 磁盘数估算；
4. 分页陷阱：深分页用游标（WHERE id > last_id）替代 OFFSET。

这些细节看起来琐碎，但在企业信息系统开发中，一次正确的索引调整往往比升级硬件更立竿见影。

实践建议：把优化前置到设计阶段

我们服务客户做 IT 技术外包时，习惯在需求评审阶段就输出数据量预估表——未来一年表行数、日均增长、峰值 QPS。基于这张表决定是否分库分表、是否引入读写分离。数字化运维阶段则通过 Prometheus + Grafana 监控慢查询、连接数、缓冲池命中率，让问题在用户感知之前暴露。

数据库没有银弹，只有与业务节奏匹配的取舍。无论是网站定制开发还是复杂的行业解决方案，把数据层的功课做在前面，系统的生命周期才能走得更远。这也是我们在每个南京本地项目中坚持的技术底线。