准备声明对于正常查询是浪费的？ (PHP)

现在,“准备声明”似乎是任何人建议向数据库发送查询的唯一方法.我甚至看到建议使用准备好的语句存储过程.但是,对于额外的查询准备语句要求,以及它们最短的时间,我被说服只对一行INSERT / UPDATE查询有用.

我希望有人可以纠正我的这个,但它似乎是一个重复的整个“桌子是邪恶的”CSS的东西.如果用于布局而不是表格数据,表格只会是恶意的.使用DIV的表格数据是对WC3的风格违反.

像智慧一样,纯SQL(或从AR生成的)似乎对80％的查询使用更为有用,大多数站点是单个SELECT,不再重复页面加载(我在谈论脚本语言像PHP这样).为什么要让我的过税数据库准备一个声明,只能在被删除之前运行一次？

MySQL的：

A prepared statement is specific to
the session in which it was created.
If you terminate a session without
deallocating a previously prepared
statement,the server deallocates it
automatically.

所以在你的脚本结束时,PHP会自动关闭连接,你将丢失准备好的语句,只是让你的脚本在下次加载时重新创建.

我是否缺少某些东西,还是只是减少表现的一种方法？

：更新时间：

对我来说,我正在为每个脚本假设新的连接.我假设如果使用持久连接,那么这些问题就会消失.它是否正确？

：UPDATE2：

似乎即使持续连接是解决方案 – 对于大多数Web来说,它们都是not a very good option,尤其是在使用事务时.所以我回到了正方形,没有什么比下面的基准进行…

：UPDATE3：

大多数人只是重复短语“准备好的语句防止SQL注入”,这并不能完全解释问题.为每个DB库提供的“转义”方法也可以防止SQL注入.但它不止于此：

When sending a query the normal way,
the client (script) converts the data
into strings that are then passed to
the DB server. The DB server then uses
CPU power to convert them back into
the proper binary datatype. The
database engine then parses the
statement and looks for syntax errors.

When using prepared statements… the
data are sent in a native binary form,
which saves the conversion-CPU-usage,
and makes the data transfer more
efficient. Obviously,this will also
reduce bandwidth usage if the client
is not co-located with the DB server.

…The variable types are predefined,
and hence MySQL take into account
these characters,and they do not need
to be escaped.

07001

感谢OIS终于在这个问题上设置了海峡.