准备好的声明与存储过程

如果您使用的是php5和mysql5,那么在预处理语句中使用存储过程是否有很大的优势？(我读到某处你可能无法从mysql5存储过程中获得实质性的性能提升)

1> Toby Hede..：

---

它们实际上不是一回事 - 使用存储过程,数据库逻辑驻留在数据库中.准备好的语句基本上避免在多次调用查询时重新解析查询 - 性能优势可能会有很大差异.

使用其中一种的选择实际上取决于您的具体情况.我不再使用存储过程,因为我喜欢在一个地方拥有所有逻辑.

---

存储过程可以使用预准备语句.无论您是否使用存储过程,都应使用预准备语句.

---

究竟.我看到了这个问题,摸不着头脑.真的,你可能需要两个:准备调用存储过程.就个人而言,不使用准备就是申请死亡的愿望.您需要以某种方式清理数据.

2> 小智..：

---

存储过程对专业级(IE企业级)应用程序有意义,您可以在这些应用程序中:

希望允许数据库工程师优化查询性能

想要将查询的复杂性抽象为简单的API

希望您的逻辑分布,因为数据库中发生的某些事情可能是您不希望向其他方公开的知识产权

希望您的逻辑分布,因为这是分布式n层计算的本质

您可能希望数据库工程师或DBA在不修改应用程序代码的情况下修改模式(存储过程,通过提供API,提供一层抽象)

还有其他原因.

准备好的陈述对于在会话中完成的工作更好.但是如果你花时间创建一个准备好的语句,你基本上已经完成了创建存储过程所需的一切.不同之处在于存储过程可在多个会话中使用(受数据库中的GRANTS限制).

我无法弄清楚的是,如果你有存储过程与预备语句的选项,为什么你会打扰准备好的语句.大多数SP与PS的讨论似乎都关注它们之间的差异,而不是为什么要使用一个与另一个.这似乎总是归结为"取决于你想要做什么." 但我没有看到一个组织良好的描述:如果你需要VS使用一个proc如果你需要使用一个声明....

3> Barry Austin..：

---

存储过程的一些优点:

语言之间便携

对于复杂查询尤其是多查询事务,可以简化界面,有时可以提高性能(测试!)

通过公开接口而不是表,可以用来提高安全性和完整性

存储过程的一些缺点:

将业务逻辑放入数据库 - 使设计复杂化,追踪版本控制和故障排除的额外位置

在某些情况下性能损失(测试!)

数据库之间的可移植性

我认为这个问题不存在单一的通用答案,因为根据情况有利有弊.如果您遵循简单,干燥,测试和避免过早优化等原则,您可能会很好.