如果您使用的是 php5 和 mysql5,那么使用存储过程相对于准备好的语句有很大的优势吗?(我在某处读到你可能无法从 mysql5 存储过程中获得实质性的性能提升)
7 回答
它们并不是一回事——对于存储过程,您的数据库逻辑驻留在数据库中。如果多次调用准备好的语句,它们基本上可以避免重新解析查询 - 性能优势可能会有很大差异。
使用一种或另一种的选择实际上取决于您的具体情况。我不再使用存储过程,因为我喜欢将所有逻辑放在一个地方。
存储过程适用于专业级(IE 企业级)应用程序,您可以:
- 希望让您的数据库工程师优化查询以提高性能
- 想要将查询的复杂性抽象为简单的 API
- 希望您的逻辑分发,因为数据库中发生的某些事情可能是您不想向其他方公开的知识产权
- 希望您的逻辑是分布式的,因为这是分布式、n 层计算的本质
- 您可能希望数据库工程师或 DBA 在不修改应用程序代码的情况下修改模式(存储过程,通过提供 API 提供抽象层)
还有其他原因。
准备好的陈述更适合在会话中完成的工作。但是,如果您花时间创建准备好的语句,那么您基本上已经完成了创建存储过程所需的一切。不同之处在于存储过程可跨多个会话使用(取决于数据库中的 GRANTS)。
What I can not figure out is that if you have the option for stored proc vs. prepared statement, why you would bother with prepared statements. Most of the SP vs PS discussions seem to focus on what the differences are between them, not on why to use one vs the other. That always appears to boil down to "depends on what you are trying to do." But I haven't seen a well organized description of: use a proc if you need VS use a statement if you need....
存储过程的一些优点:
- 语言之间可移植
- 可以说是简化的界面,有时对于复杂查询,尤其是多查询事务(测试!)
- 通过公开接口而不是表,可用于提高安全性和完整性
存储过程的一些缺点:
- 将业务逻辑放入数据库 - 使设计复杂化,为版本控制和故障排除提供额外的跟踪位置
- 某些情况下的性能损失(测试!)
- 数据库之间的可移植性较差
我认为这个问题不存在单一的通用答案,因为根据情况有利有弊。如果您遵循简单、DRY、测试和避免过早优化等原则,您可能会得到很好的结果。
在这里可能不是这种情况或值得一提,但存储过程在它们与语言无关的情况下也是“可移植的”。您可以像使用 PHP 一样从 Java 内部调用数据库上的相同存储过程。因为过程驻留在数据库中,所以可以访问数据库的任何东西都可以以相同的方式查询它们。
存储过程的主要优点是您的数据在应用逻辑之前不会跨越层(在这种情况下它将是 PHP/MySQL 层)。某些查询可能需要多个 select 语句,通过 PHP 完成的速度比在 MySQL 中要慢。
现在,正如Tobyhede 所指出的,将所有逻辑放在一个地方是件好事。但是我从事过使用 PHP 查询所需数据根本不现实的项目。它必须通过存储过程来完成。
首先我会说我不喜欢存储过程的想法,我宁愿走准备好的语句路线。在这种特殊情况下,我认为您还将苹果与橙子进行比较……它们都具有完全不同的功能……
如果应用程序是 95% 的数据库驱动,我只会考虑存储过程,只有在数据库中有一些逻辑才有意义。
不熟悉 php,但通常存储过程已经“编译”,因此可能会比 sql 语句产生稍快的性能。
尽管从代码管理/部署和单元测试的角度来看,我通常更喜欢坚持使用 SQL。