SQL 人要敢于说不

“哎，小 C 帮导个数据，很简单，我只要 5 万条”

 

我们组的小姑娘经常会被这种无脑的要求，折腾得哭笑不得。曾几何时我做 SQL 开发的时候也经常遇到这种不定期，无规范的 ad hoc 查询。这是数据应用初期常有的拍脑袋案例。

 

但如果真的开了这种口子，我们来猜猜会怎么样：

 

各个部门都要来开这样的接口，一次导出数据，具体数据量不可控；有时候，多个部门同时开始导出全年或者前 5 年的历史数据；然后，你的系统经常无缘无故被投诉拖卡慢，然后你的年终奖，886.

 

然后我们来说说小 C 面对的这个业务提出的需求，导出 5 万条数据，真的是很困难么？为什么要告诉业务，“你这个需求不简单，难！！！”

 

首先，你司的系统并不是为你一个人/部门服务的。

抛开你的个人烦恼先不说。你先了解下你们公司有多少部门，多少人在用这套系统。假如每个人都想开个独特的流程去导个数万条数据，无疑加大了你们这套系统的负荷。加上原本这套系统可能就服务了上百万名用户（互联网公司用户特别多），那么每个部门都同时拉取数万条数据有可能就直接把内存、硬盘 IO、网络给占爆（再说一遍，你司的系统并不是为你一个人/部门服务的）

接着，说说技术上的不可实现。

基于第一点，假设有很多部门都在同时拉取数万条数据，从技术上来讲，数据都是从硬盘读到内存，经由网络输出到你部门。大批量的数据必定占用高内存，高 IO, 高网络占用率。任何经过严格控制的 OLTP 系统并不会给到这么一个接口，让大家都去无限量的读取数据。有时候为了数据库的稳定，我们还会对数据接口做限流和熔断。

最后，解决你要导出数据的问题。

你做了活动，要做一些数据分析和统计，这是件头等大事。数据运营在 BAT 是常见的手段了，所以这样的需求要培养，要规划。养数据到用数据，是企业信息化的必经之路。但为了系统的稳定，必须采用特殊架构来帮助更好、更健壮、更有效率的完成数据分析的工作。这就涉及到数据架构规划的问题了。业界最佳实践采用的是读写分离架构。写操作放在 MySQL 实时进行，而读数据（也就是满足你数据需求的操作）就放到另一台数据归档（简称数据仓库）服务器上进行。此时，你提出拉数据的需求，可以让服务器的任务管理器帮你调度，而不影响其他任务的执行。

 

昨天在曹大的星球中，发现一个好玩的收二手书的小程序。老读者肯定知道我其实还算得上比较爱看书的那种，所以我的读者肯定都是爱读书的，推荐给大家。

如果你有旧书 放到这上面来卖 让原本的书的价值在此流动起来 你还可以低价重新购买别的书