这是一个创建于 2349 天前的主题，其中的信息可能已经有所发展或是发生改变。
新领导要求不要用存储过程，说因为存储过程太复杂，后续的人不好接手... 要求所有数据的处理都读出来用 java 程序处理，比如复制一张表：先 select 到对象中，再把这个对象 insert 到目标表...和他说 CTAS，他说太复杂，和他说效率，他说可以加机器...
如果说过于依赖存储过程会对后续数据库迁移有影响我觉得是有道理的，但他貌似根本没想到这一层，而且既然用数据库了，不能用 SQL 实在不能理解
 | 1 ebingtel 2019-06-30 15:55:31 +08:00  21 我也觉得你领导是对的……好的程序大把，好的 DBA 凤毛麟角……自己觉得顺手，后面给谁维护呢？ |
 | 2 cloudbeyond 2019-06-30 16:00:02 +08:00 5 领导是对的，程序易改，数据库难改，程序好扩展，数据库不好扩展。用廉价资源保护重要资源 |
 | 3 lihongjie0209 2019-06-30 16:03:29 +08:00 4 数据库不带任何业务逻辑是正确的做法 |
 | 4 sunny352787 2019-06-30 16:05:36 +08:00 3 再加一条，存储过程没法进行版本控制 |
 | 5 Takamine 2019-06-30 16:06:05 +08:00 via Android 1 领导是对的。 当远古业务用存储过程发生死锁的时候，你可知多刺激。 |
 | 6 annielong 2019-06-30 16:06:36 +08:00 是不是前后端分离，有专业的 dba 吧，有些需求还是存储过程好用，我手头经常定制新增定制报表，就前台做一个通用类，数据一个报表一个过程，新增修改直接在数据库改，也不用发布新版本 |
 | 7 niubee1 2019-06-30 16:06:56 +08:00 存储过程是用小机装 Oracle 时代的做法了，实际上等于是把业务逻辑和数据存储耦合在一起了 |
 | 8 aborigine 2019-06-30 16:09:30 +08:00 存储过程很简单，但是维护很麻烦很难，要是改需求就更恶心了 |
 | 10 v2overflow OP @cloudbeyond 问题是 SQL 都不用的话，还用数据库做什么…我们是做批量维护的功能，大部分应用场景就是根据某些条件去更新某字段，以及备份，加载这些，复制表用 java 一条一条的 select 再 insert 这种我真是从来没想到过 |
 | 11 pagxir 2019-06-30 16:18:17 +08:00 via Android 这不是难不难的问题，而是该不该的问题。 |
 | 12 PerFectTime 2019-06-30 16:21:16 +08:00 然鹅我司就是遇到了 5#所说的远古业务死锁的问题.... 简直一座屎山... |
| 13 v2overflow OP @pagxir 其实我觉得不用存储过程我可以接受，我也说了可移植性不好，但领导那边连标准 SQL 都要求避免使用…… |
| 14 pagxir 2019-06-30 16:25:35 +08:00 via Android @v2overflow 这要取决于你们的业务，还是该不该的问题。 |
 | 15 metrxqin 2019-06-30 16:30:49 +08:00 18 傻子才用存储过程，知道为什么吗？ 可维护性 0 可测试性 0 可重用性 0 可扩展性 0 可移植性 0 |
 | 16 dobelee 2019-06-30 16:34:44 +08:00 via Android 1. 存储过程不难 2. 你领导是对的 |
 | 17 oaix 2019-06-30 16:58:57 +08:00 就楼主说的这个需求不是可以用 insert into select 语句吗，这也不让用吗？ INSERT INTO table2 SELECT * FROM table1; |
 | 18 akira 2019-06-30 17:30:21 +08:00 交次学费就知道为什么不用存过了 导数据那个不用 ctas，应该是有别的原因 问具体呗 |
| 19 v2overflow OP @pagxir 我认可根据业务功能去做技术选型，之前也一直是这么做 但新来的领导要求所有问题都统一，比如不用存储过程就连 SQL 也都不用，不管应用场景，字段求和就是记录扫出来 java 里面加，update 就是符合条件扫出来，java 改字段再 update 进去，这种真的是好设计么？还是我思想过时了？ 另外，移植性，灵活性是理由，我认可 难度，可维护性我不觉得有什么问题 |
 | 20 wd 2019-06-30 17:41:41 +08:00 via iPhone 进了垃圾公司，后续都是招聘垃圾程序员，自然没有几个能接存储过程的。解决办法就是进个牛逼公司，进不去就听你领导的。 |
 | 21 yidinghe 2019-06-30 17:45:34 +08:00 via Android 这个也太绝对了，我这边就是直接 insert...select 一条语句搞定，复杂吗。但如果是存储过程确实能不用就不用，我们新系统数据迁移，虽然 dba 给了迁移的存储过程，但我们决定还是用代码来做，为什么，因为迁移完了还要有很多校验，dba 要做这个的话就必须学习每张表的业务逻辑。这种事 dba 是不干的。 |
 | 22 jingyulong 2019-06-30 17:54:31 +08:00 有 DBA 的时候，就可以用存储过程了。有些特别复杂的业务，使用 SQL 效率会很高，看实际业务了。 |
 | 23 loading 2019-06-30 19:25:10 +08:00 存储过程写的时候不难，读？基本不可能！ |
 | 24 wc951 2019-06-30 19:28:10 +08:00 via Android 还有一点就是关系型数据库单打天下的时代过去了 |
 | 25 nidaye999 2019-06-30 19:43:38 +08:00 看来楼主还在坚持自己的想法。做事要考虑周全，不要只想自己。参考其他人的意见是不错的选择。 |
 | 26 fox0001 2019-06-30 19:46:34 +08:00 via Android 一般不能用存储过程的都不用。缺点正如 @metrxqin #15 所言。 对于原有的存储过程，目前的维护是： 1 ）用程序重新实现 2 ）不能重新实现的，全部导出 SQL 文本，做版本控制，并且加上注释。（基本没有这种情况了） 剩下视图也是导出 SQL 文本做版本控制。 |
 | 27 applehater 2019-06-30 19:50:11 +08:00 不好调试，没执行记录，容易留 BUG 还不好确定，不能咬定是别人的问题。我现在就遇到这样的问题。 |
 | 28 zander1024 2019-06-30 20:12:09 +08:00 有好的 dba 的时候可以用存储,但是不保证好的 dba 一直在你公司啊... 真的,程序找问题比存储找快多了。 |
 | 29 zclHIT 2019-06-30 20:32:48 +08:00 歪个楼： 要么。。。 要么。。。 要么。。。 对吧? |
 | 30 ty89 2019-06-30 20:36:35 +08:00 7 当你只有一把锤子的时候，你看所有东西都像钉子 |
 | 31 GG668v26Fd55CP5W 2019-06-30 20:48:29 +08:00 via iPhone 可别用这玩意，老糟心了 |
 | 32 zr8657 2019-06-30 21:09:10 +08:00 我觉得 30 楼说的入木三分 |
 | 33 springz 2019-06-30 21:24:53 +08:00 特定行业吧，如果是做 ERP 或者特定行业，存储过程好用。 |
| 34 springz 2019-06-30 21:25:24 +08:00 并不是每个产品都会面临频繁变化的需求的 |
| 35 springz 2019-06-30 21:30:55 +08:00 1 当数据越来越大，面临分库分表的时候，就知道什么存储过程，视图，触发器等等这些上古时代的垃圾会变成屎让你一点点吃下去。存储过程是最大最硬的屎。 |
| 36 springz 2019-06-30 21:37:21 +08:00 @v2overflow V2EX 上很少传统企业程序员，大家都是被数据库坑过的人，思路可能不同。为了最大的扩展性，大多数情况下别说存储过程了，关联查询建议最好不要使用的。 |
| 37 springz 2019-06-30 21:40:45 +08:00 建议看下 阿里巴巴开发手册 数据库部分 |
 | 38 NeinChn 2019-06-30 21:43:10 +08:00 还有类似的关联问题： “为什么外键这么好用领导不让用” “为什么书里教的范式这么好用领导还要搞一堆冗余字段” “为什么 group by 这么好用领导不允许在线上直接用，只允许在统计从库 /Hive 上用” 要是业务就那么小那么简单，随便用，要是业务还有增长的机会，那就还是别用了 |
 | 39 redtea 2019-06-30 21:44:17 +08:00 via iPhone 存储过程是毒药 |
 | 40 xaplux 2019-06-30 21:44:29 +08:00 不要写存储过程 不要写存储过程 不要写存储过程！ 禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。 |
| 41 springz 2019-06-30 21:46:22 +08:00 问错地方了，这里大家吃屎吃多了，大部分都应该是把数据库当做一个可靠的 K/V 库用的，数据库本身的特性能不用最好不用。 |
 | 42 LeeChP 2019-06-30 21:50:24 +08:00 via iPhone 1 你可能不知道一个项目里有几万行存储过程是什么体验，我们一般用两个字形容这种架构师，傻逼！ 维护一下，你就懂了！ |
 | 43 weiming 2019-06-30 21:50:36 +08:00 领导没毛病，所有的存储过程一经使用都是遗留代码，过半个月你自己都不认得是谁写的。 |
| 44 springz 2019-06-30 22:07:04 +08:00 @v2overflow 翻了下记录，你说对了 SQL 真不是必选项。 |
 | 45 feiyunruyue 2019-06-30 22:15:38 +08:00 你见过 2000 行的存储过程吗？又想起来被存储过程支配的恐惧了。 |
 | 46 luckylo 2019-06-30 22:33:27 +08:00 via Android 什么年代了，居然还有人想着用存储过程？？回帖里基本都是否定这种的。如果你不信，你可以写个几百行存储过程，隔一两个星期再去阅读试下。 |
 | 47 opengps 2019-06-30 22:38:14 +08:00 via Android 我也这么觉得，一般的小公司普遍用人紧张，牛人留不住，做项目不敢做的太高深怕被员工牵制 |
 | 48 cabing 2019-06-30 22:45:26 +08:00 确实是很快恐怖。 领导考虑的比较全量，是个好领导。 |
 | 49 woshifyz 2019-06-30 22:49:11 +08:00 1 新人就多学习，别天天想着领导是 sb |
 | 50 tairan2006 2019-06-30 22:58:29 +08:00 只有在证券公司呆的时候见过存储过程，互联网公司没见用过的… |
 | 51 luozic 2019-06-30 23:01:01 +08:00 via iPhone 存储过程依赖具体数据库，甚至依赖具体版本的数据库，你说呢。 |
 | 52 wenzhoou 2019-06-30 23:20:15 +08:00 via Android @oaix 就算你说的这个场景。你能保证业务不变更吗。 回头领导一句话，你个我把这个字段和这个字段合并一起。然后你就傻眼了。还是得要换成应用侧处理。 所以我觉得，别费那么大劲。就给搞成 Java 的。能跑就这么跑，不坑后人。 |
 | 53 txy3000 2019-06-30 23:30:52 +08:00 via Android 1000 行的存储过程 玄学调试 |
 | 54 ps1aniuge 2019-07-01 00:01:15 +08:00 5 新领导要求不要用存储过程，说因为存储过程太复杂，后续的人不好接手... 要求所有数据的处理都读出来用 java 程序处理--------这样的人和公司和论调大把，甚至阿里也是这样说。但我说这纯属放 p。这是程序员 dis，dba 的一种说法。是程序员 dis 数据库开发人员的一种说法。 和“ php 是世界上最好语言”一样，是一种偏见！！！ 存储过程没法进行版本控制-----凡是语言都能进行版本控制。 数据库不带任何业务逻辑是正确的做法。------这是不可能的！ 业务需求数据库带有逻辑。你这种论调，只是把逻辑用另一种语言来实现而已。 正确的是，数据库必须带有逻辑， 必须带有冗余。 必须分冷热数据。 必须带有子库。即子库+母库。而字母库 1，又和字母库 2 互联。形成分布式库。 字母库之间必须用语言，来互通消息。 字母库之间必须用语言，来搬运数据。 至于用这种语言，还是那种语言。用不用 sql，要扬长避短，而不是一味 diss sql。 有的时候，你不用 sql 事务，你难以解决死锁。 你不用唯一索引，难解决重复问题，要用程序，你就要引入分布式全局锁。 这些难题用数据库，一下子就解决了，或一下子就没有了。 一味 diss，我想大概有这么几个原因： 1 没有 dba。但应用开发人员很多，所以强势。 2 感觉，存储过程，sql 难，反人类。不好调试，没执行记录。------这些是 [应用开发人员] 偏见， [库开发人员] 不这么看。 3 感觉 dba 难以沟通。难以协调 [应用开发人员] 和 [库开发人员] 之间的工作。 结论： 是偏见，但是偏见者众。 数据库应该分层，第 1 层应该是内存的，因为快，应该是亲 [应用开发人员] ，如 redis。 第 2 层，第 3 层。每层（字母库）之间有冗余，有逻辑整理，逐渐分冷热。逐渐符合数据库范式。 |
 | 55 hiboshi 2019-07-01 00:15:16 +08:00 领导是对的,不是每个人都会存储过程。未来也不好交接，没有专业 DBA 团队的公司不要用，互联网公司也不要用。很坑 |
 | 56 lincanbin 2019-07-01 03:21:58 +08:00 via Android 我工作这么多年，还没见过有用存储过程的公司。 |
 | 57 jaskle 2019-07-01 07:25:35 +08:00 via Android 偷偷的告诉你:存储过程很简单，也没有第三方库，就一个好处:快！比任何方式操作数据库都快！没有可比性，尤其涉及到多表数据分析，用外部语言简直慢的不行，大量的网络 io 交换，大量的计划，总之存储过程就一个字:快！ but，一堆维护问题，线上数据库基本不支持，移植基本死翘翘 |
 | 58 skiy 2019-07-01 09:40:06 +08:00 运营过程中就遇到过这坑。排查程序压根没发现问题。最后才发现是存储过程的问题。折腾死了。 |
 | 59 abcbuzhiming 2019-07-01 09:45:13 +08:00 你领导没错，存储过程的维护成本和程序的维护成本完全不是一个级别的。除非不得不用存储过程，否则别用存储过程 |
 | 60 Y4ssss 2019-07-01 09:47:23 +08:00 看到存储过程里，上千行的包含业务逻辑的 sql，你就知道为什么不推荐使用存储过程里 |
 | 61 killerv 2019-07-01 09:51:38 +08:00 数据库这种底层的东西最好不要和业务有什么牵扯。 |
 | 62 dog82 2019-07-01 09:53:47 +08:00 我自己是 DBA 出身，我是支持在项目中用存储过程的。 但是要区分场合，事务性的肯定要写在代码里，报表和数据转换之类的操作用存储过程更简单直接 |
 | 63 liuxey 2019-07-01 09:54:49 +08:00 如何你们有专职的 DBA，让他去说服领导，如果没有，你不要凑热闹 |
 | 64 whywhywhy 2019-07-01 09:56:46 +08:00 @lincanbin 我这边是 ERP 软件甲方，乙方不给开放二次开发，乙方自己开发又慢，测试又不尽力，开发又不尽力。有时候真的超级烦，有的逻辑超想帮他们全部写好细节让他们直接搞直接修…… 然后有一天发现他们使用存储过程，于是就进去看……虽然不是 SQL 达人而且只会入门语句，竟然也看懂了不少。顿时对存储过程好感提升…… |
 | 65 alexmy 2019-07-01 10:15:45 +08:00 换了一批人维护，后者肯定会诅咒前面写存储过程的人的。 |
| 66 wenzhoou 2019-07-01 10:21:57 +08:00 via Android 3 @ps1aniuge 也有可能不是偏见，是教训呢？ 我们线上的机器，应用服务器十几台，如果 CPU 或内存不够了，再上七八台很容易。应用服务器崩了就崩了没事的。 数据库服务器，就两台，如果 CPU 或内存不够了，整个业务死翘翘。 为什么不多搞几台，因为代价和应用服务器不是一个数量级的。我们用的 Oracle 的版权死贵，出了问题请 Oracle 专家来，那个价格真心不便宜，而且耗时间等不起。 曾经出现过，调查 bug 的人去服务器上敲了一条 select 语句，导致生产数据库长时间没反应。后果可想而知。从那以后所有人就知道把数据库服务器当宝贝了。 数据库服务器，就是要 io 性能超好，你看似一次检索出来的数据量太大，但是就算是几百 M 数据这对于内网的数据库，都不是问题。反而是 CPU，有两个问题。一个是版权是按照 CPU 内核数收费的，再一个 CPU 再好也经不起折腾，你把排序，数值加减放到数据库服务器上运算，那就是拿着尚方宝剑去切肉。所以一般数据库专用服务器都放弃 CPU 了。 所以说不是不想用存储过程，实在是条件不允许。 当然你单机跑，或者没上线之前做数据移行，那随你高兴。 所以再强调一遍，不要在数据库服务器上玩火是绝对政治正确的。 |
 | 67 calming 2019-07-01 10:23:17 +08:00 写存储过程完全是给后面人挖坑 |
 | 68 Ritr 2019-07-01 10:27:29 +08:00 开发难度：★ 维护难度：★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ |
| 69 lihongjie0209 2019-07-01 10:28:09 +08:00 |
 | 70 Sypher 2019-07-01 10:32:41 +08:00 |
| 71 Sypher 2019-07-01 10:33:09 +08:00 屎山这个词笑死我了 |
 | 72 Caballarii 2019-07-01 10:42:20 +08:00 当年还是菜鸟程序员的时候遇到有外键删不掉数据这种事以后，我就发誓再也不在数据库上搞任何带有业务逻辑的东西了嘿嘿 |
 | 73 youEclipse 2019-07-01 10:43:04 +08:00 @LeeChP 给架构师倒一杯卡布奇诺 |
 | 74 FrankHB 2019-07-01 10:43:38 +08:00 @v2overflow 醒醒，DBMS 不是 RDBMS，没空没历史遗产倒腾啥 SQL。 |
 | 75 la2la 2019-07-01 10:43:46 +08:00 挺正常的，我们这主库的数据，要定时放到测试库中和定时清理到 hive 中(大的表数据上亿了)，本来建议使用 kettle，但是领导坚持写 python 脚本,不过好处就是脚本大家都看得懂，有人请假问题也不大。 |
| 76 FrankHB 2019-07-01 10:49:43 +08:00 4 > 存储过程没法进行版本控制-----凡是语言都能进行版本控制。 肤浅。控制到什么程度？“凡是语言”？给你一坨 Piet 代码你能 diff 得让人看？ > 你这种论调，只是把逻辑用另一种语言来实现而已。 废话。只是工程上能用的“另一种”语言想要比带所谓存储过程的语言实现此类需求能力更稀烂还是不太容易的。 > 必须带有子库。即子库+母库。而字母库 1，又和字母库 2 互联。形成分布式库。 前面的瞎眼论调先无视。整个生命周期都没要分布式的业务，照你这坨还应该没事瞎搞个分布式架构？这是什么精神？ > 2 感觉，存储过程，sql 难，反人类。不好调试，没执行记录。------这些是 [应用开发人员] 偏见， [库开发人员] 不这么看。 抛开实现是不难。但是[语言开发人员]就是要 diss 一坨不知本分还要跨领域碰瓷的 DSL 了，不服？ |
 | 77 shuizhengqi 2019-07-01 10:54:41 +08:00 我还真没见过存储过程，你是刚从书上学来的？ |
 | 78 Actrace 2019-07-01 10:56:03 +08:00 你遇到了一个好领导，珍惜啊。 |
 | 79 Actrace 2019-07-01 10:57:01 +08:00 补充一下，SQL 本质还是查询语言，用来做逻辑性的事情总感觉不合适。 |
 | 81 brust 2019-07-01 10:59:10 +08:00 有存储过程的项目就是一座屎山 不过有一个好处,如果自己维护简单,别人维护复杂 写出了别人难以维护或者无法维护的代码相当于增加自己的核心竞争力 当然前提是这个模块很重要,无法被重构的那种 |
 | 82 wysnylc 2019-07-01 11:03:09 +08:00 首先存储过程是垃圾 其次业务逻辑在代码中没有丝毫问题,分布式就是要去 join 去子查询才能拆分数据库,join 会导致表之间关联锁死无法拆分 |
 | 83 JohnSmith 2019-07-01 11:11:29 +08:00 过来人经验，sql 服务器经常莫名高资源占用，没有 trace 信息，找不到原因，代码无法维护，难以 debug。重构也相当困难，害人害己！ 存储过程可以类比成现代框架中的 faas，但是缺少必要的 trace，metrics，log 以及统一的控制后台。 在类比一下，就和微服务架构缺少 devops 一样～ |
 | 84 onionKnight888 2019-07-01 11:13:58 +08:00 维护过上古业务的存储过程，真是恶心吐了 |
| 85 JohnSmith 2019-07-01 11:17:52 +08:00 任何团队项目都需要重视工程规范和工程标准化 |
| 86 FrankHB 2019-07-01 11:19:44 +08:00 @Actrace SQL 名义上确实是“查询”（“ Q ”）语言，但规格上至少包含 DML/DDL/DCL。以查询为中心的 SQL 名义上是声明式语言，但实际上已经是大杂烩了。 实际实现野心更大，什么乱七八糟的功能都想掺和（很多所谓内置函数的干活附会到“查询”上也是可以的，但本质早就和 DB 无关了），给 DBA 偷懒以外就是给手贱不懂正确选型的开发喂屎而已。 “可扩展”的存储过程算是这种不切实际的鸡肋野心的进一步实现。半吊子 UI 能顶几个靠谱的 API 呢，谁用谁知道，是不是混了斯德哥尔摩综合症就难说了…… |
 | 87 l00t 2019-07-01 11:20:53 +08:00 1 从没觉得存储过程不好维护…… 写得是不是容易让人理解，这得看写的人的风格，和读的人的习惯。同一个操作，你可以写成很多人理解有困难的集合运算，也可以像别的语言一样游标里 for 一下逐条处理。要说行数太多，也完全可以拆分成多个函数和存储过程，甚至加入 package，和别的语言有啥大区别？纯粹是技术栈的问题罢了。 不能版本控制更是扯谈。在数据库里编译运行的就不能把代码拉出来写成脚本单独管理了？ 另外写存储过程的语言不是 SQL ！它只是能无缝集成 SQL 罢了，本质上和 SQL 还是两种不同的语言。 不容易横向扩展倒是真的。 |
 | 88 VictorJing94 2019-07-01 11:23:36 +08:00 存储过程是很好的解决方案.... |
 | 89 jsnjfz 2019-07-01 11:29:36 +08:00 看过几千行存储过程的飘过。。。其实不算复杂的，但是不利于管理 |
 | 90 ericgui 2019-07-01 11:32:29 +08:00 @lihongjie0209 +1 |
 | 91 rockyou12 2019-07-01 11:35:47 +08:00 任何系统（软件也好，盖房子造飞机也好），性能都不是最重要的，健壮性才是，而且是用血的经验总结出来的。 上面还是有部分回复觉得存储过程没问题，你要是有个存储过程跑了几年而且不会去改那才是没有问题。我们现在生产就有业务依赖存储过程，每年总有 1、2 次会有死锁然后要手动重启。好像不是大问题但每次都只有客户说了我们才知道，体验极差。 可能又有人说这是你们数据库维护水平不行，废话，你是领导同样的钱，或者给你同样时间让你学习，你是要精通数据库何种边边角角功能，还是精通业务开发能快速把业务写好 bug 又少的。 |
 | 92 wupher 2019-07-01 11:44:38 +08:00 1 它们都只是技术而已，使用的情况么，看场景。 CS 程序员和产品会更喜欢存储过程。比如 XX 管理系统，XX 财务系统，主要业务逻辑都是使用存储过程封装。到客户那边修改逻辑实现，去数据库中改下存储过程即可，而不是使用 Delphi、C#、VC 什么的重新编译一个客户端或者 DLL，再部署。 但是在 Web 后端看来，这个解决方案就坑了。你写成 Java、C# 、Python 什么的，可以在无数应用服务器上并发运行。写成存储过程，就只能在数据库里面跑了。性能相差可能数据级别。存储过程，后面如果碰上数据迁移，比如 Oracle 转 MySQL、MySQL 转 HBase 基本上全得重新开发，而后端服务不受此影响。 都是抉择，无非取舍而已。 |
| 93 l00t 2019-07-01 12:30:19 +08:00 @rockyou12 #91 死锁和存储过程有啥关系？同样的代码你换个别的语言写就不死锁了？出现死锁，首先要排查出真正的原因，而不是推到存储过程上面。 |
| 94 lihongjie0209 2019-07-01 12:44:29 +08:00 @l00t 存储过程怎么排查死锁问题? |
| 95 l00t 2019-07-01 12:45:38 +08:00 @lihongjie0209 #94 你别的语言怎么排查存储过程就怎么排查啊。 |
 | 96 Vegetable 2019-07-01 12:48:30 +08:00 主要还是这门技术不够现代化 |
 | 97 jiom 2019-07-01 12:54:51 +08:00 之前交接前辈的储存过程，我看了一个月，8K 多行。回想一下，想哭 |
| 98 lihongjie0209 2019-07-01 13:07:06 +08:00 @l00t 打断点, dump 线程, 写日志 存储过程可以做到哪一步? |
 | 99 q397064399 2019-07-01 13:09:53 +08:00 Structured Query Language 干好 Query 的事情就好了，迁移这些东西 说得不好听点，除了一行 SQL 跟 update insert 能搞定的事情， 最好不要用 SQL，存储过程无法调试，MySQL 那个报错又是反人类中的反人类，而且这东西没有 Trace 没有 Log , 鬼知道线上迁移的时候会出什么幺蛾子，用 Java 迁移 至少知道哪一块出了问题 ------ 另外你真的遇到了一个好领导了，我之前在的一个公司 领导恨不得把存储过程 人手普及一下， 说实话很多数据库的东西 都可以扫进垃圾堆了。 另外 DBA 如果看不懂代码操作了什么，我一般都是建议 用 Java 直接生成中间的 SQL 脚本 打死也不用存储过程 |
| 100 l00t 2019-07-01 13:10:38 +08:00 @lihongjie0209 #98 每一步都可以啊 |
Select Language