mysql为什么不使用存储过程_mysql 为什么不用存储过程?

你的位置:

问答吧

-> MySQL

-> 问题详情

mysql 为什么不用存储过程?

看一个大型网站 准备性能优化(java+linux+mysql)

突然发现该网站java代码全部用sql 不用存储过程

仔细看os 是centos

mysql是5.0.4(非企业版本)

我觉得从直觉还是应该用存储过程.(1次编译,之后就快)

作者: liyihongcug

发布时间: 2009-04-27

朋友是DBA嘛，使用存储过程的话，可能会把一些逻辑运算放到服务器端了，这样会加大服务器的负责，特别是并发量大的应用，更不能这样做，可能导致前端应用迟迟拿不到数据，若是单条SQL就可以更快拿到结果，消耗更少的资源

.........................................

你再想想，嘿嘿....

作者: jinguanding

发布时间: 2009-04-27

我不是这样理解的

1对于某些返回行纪录很多的情况，存储过程发挥很大作用，第1次编译之后，之后不用再编译，直接走执行计划

理论上要快很多的

2特别某些大表，复杂应用有时候必须用存储过程

我回忆很多年前作项目，有专家指导团队要求所有SQL代码全部转为存储过程----一方面安全性，另1方面速度理论要快

现在我当前环境确实是并发量大的应用，我觉得对于单条插入 删除 修改等操作可以不用

但是类似 SQL我觉得还是应该用存储过程   (现在我不知道mysql的内部机智)

作者: liyihongcug

发布时间: 2009-04-28

可能也与mysql的存储过程不够成熟有关。

作者: eyunbo

发布时间: 2009-04-28

java里 有 一行代码

StringBuilder strB = new StringBuilder();

strB.append("select ")

.append("   id, startDate, endDate,tournamentId,disciplineId,locationId ")

.append("from ( ")

.append("   select ")

.append("       e1.id, e1.startDate, e1.endDate, e1.tournamentId, e1.disciplineId, t1.locationId ")

.append("   from  ")

.append("      TransactionEntity te, Event_history e1, Event_history t1 ")

.append("   where  ")

.append("       te.transactionType = 1 and te.status = 1 ")

.append("       and te.eventId=e1.id ")

.append("       and e1.type = 1 and e1.isLatest='Y' ")

.append("       and e1.tournamentId = t1.id and t1.isLatest='Y' ")

.append("   union ")

.append("   select ")

.append("       e2.id, e2.startDate, e2.endDate, e2.tournamentId, e2.disciplineId, t2.locationId ")

.append("   from  ")

.append("      TransactionMultiplier tm, Event_history e2, Event_history t2 ")

.append("   where  ")

.append("       tm.status = 1 ")

.append("       and tm.eventId=e2.id ")

.append("       and e2.type = 1 and e2.isLatest='Y' ")

.append("       and e2.tournamentId = t2.id and t2.isLatest='Y') as e ")

.append(" where ")

.append("     1 = 1 ");

类似这样的 语句很多 ，想知道建立存储过程可以解决这个问题(取数据慢)？

作者: liyihongcug

发布时间: 2009-04-28

按照数据库设计原理来讲，存储过程是在db server上预编译

的，所以查询速度会比较起纯SQL语句快很多。可能是现在流行OO，导至存储过程使用的余地大

打折扣。但如果从效果上来讲，用存储过程来实现业务规则所带得DB SERVER压力，比用JAVA类

实现业务规则所带来的WEB SERVER压力要小

作者: liyihongcug

发布时间: 2009-04-29

应用很容易扩张成N台，数据库相对来说不是那么容易的吧。

对于一些访问量巨大的网站，靠数据库来跑存储过程，做计算很容易把数据库拖死。

作者: WESTLIFE_XU

发布时间: 2009-04-29

楼上，那么存储过程到底用在什么地方

作者: liyihongcug

发布时间: 2009-04-29

基本上是不参与业务处理，严禁存储过程参与业务。

主要用在dba的一些日常维护，比如数据历史迁移，比如更改merge表定义。

作者: WESTLIFE_XU

发布时间: 2009-04-29

其实我现在对数据库的理解，最纯粹的思想就是存数据，除了存储数据，保证数据的一致性之外，数据库端尽量不做任何操作。

作者: WESTLIFE_XU

发布时间: 2009-04-29

和MYSQL自身的特点也有关吧

作者: wh28556259

发布时间: 2009-04-29

QUOTE:原帖由 wh28556259 于 2009-4-29 23:00 发表

和MYSQL自身的特点也有关吧

没有关系的。

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

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

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

作者: WESTLIFE_XU

发布时间: 2009-04-29

ok, it is the reason.

So my website refuses those boring store procedure.

these suggestions are from Foreign DBA who are strong.

作者: liyihongcug

发布时间: 2009-04-30

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

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

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

不知道我的想法对不对？

作者: wdx-snail

发布时间: 2009-05-15

同意楼上观点

现在我没有用存储过程，改用了很多的 触发器

(website有 很多的并发用户 )

没有大规模的测试

作者: liyihongcug

发布时间: 2009-05-18

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

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

作者: 血月

发布时间: 2009-05-18

那是因为程序员都不愿意改程序。

存储过程在大并发的时候性能肯定比SQL语句要好的多。

我这边有好多项目例子。

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

作者: yueliangdao0608_cu

发布时间: 2009-05-18

QUOTE:原帖由 血月 于 2009-5-18 10:53 发表

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

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

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

作者: WESTLIFE_XU

发布时间: 2009-05-18

这是数据库设计最初思想

作者: jinyuhuahan

发布时间: 2009-05-19

QUOTE:原帖由 jinyuhuahan 于 2009-5-19 09:18 发表

这是数据库设计最初思想

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

作者: WESTLIFE_XU

发布时间: 2009-05-19