mysql 为什么不用存储过程?

wh28556259

和MYSQL自身的特点也有关吧

WESTLIFE_XU

原帖由 wh28556259 于 2009-4-29 23:00 发表
和MYSQL自身的特点也有关吧

没有关系的。

我经历过数据库从压力很小，那时候很多业务逻辑都用存储过程来实现，后来随着业务开始飙升，有些sql每小时的执行次数超过2000万次，单个数据库每小时的sql执行次数在几亿次左右。

这时候你会发现ebay的架构中提到的不用存储过程是很有道理的，想象一下如果每个小时执行2000万的存储过程来进行业务处理，你的cpu不一定能扛得住的。你在想象一下，如果你能把这些计算放到几十台，或是上百台app上去实现，那效果是很明显的。

[ 本帖最后由 WESTLIFE_XU 于 2009-4-29 23:10 编辑 ]

liyihongcug

ok, it is the reason.

So my website refuses those boring store procedure.

these suggestions are from Foreign DBA who are strong.

wdx-snail

我觉得用不用存储过程是与实际情况结合。

很多时候在数据库里做一些不太复杂的处理（过程中），可以大大减少前端应用的业务逻辑代码。

使用存储过程，可以提高程序的可读性与降低开发复杂度

不知道我的想法对不对？

liyihongcug

同意楼上观点

现在我没有用存储过程，改用了很多的 触发器
（website有 很多的并发用户 ）
没有大规模的测试

血月

个人感觉不是不用存储过程，而是要考虑实际的情况，一味的遵从不使用的原则，很容易走入误区的！比如说动态维护分区表，如果使用程序来实现，其复杂度还是很大的!

[ 本帖最后由 血月 于 2009-5-18 10:54 编辑 ]

yueliangdao0608

那是因为程序员都不愿意改程序。
存储过程在大并发的时候性能肯定比SQL语句要好的多。

我这边有好多项目例子。

其实并发太多能否撑得住根本不在SPROC本身。

WESTLIFE_XU

原帖由 血月 于 2009-5-18 10:53 发表
个人感觉不是不用存储过程，而是要考虑实际的情况，一味的遵从不使用的原则，很容易走入误区的！比如说动态维护分区表，如果使用程序来实现，其复杂度还是很大的!

说的是业务处理尽量不用。

如果是dba维护，比如更改merge的定义，这个我经常用存储过程来做。

jinyuhuahan

这是数据库设计最初思想

WESTLIFE_XU

原帖由 jinyuhuahan 于 2009-5-19 09:18 发表
这是数据库设计最初思想

我们现在慢慢转到这个方向，对DB的职责甚至是对oracle，mysql应该做什么很清晰。