在PHP中全面阻止SQL注入式攻击之三
一、 建立一个安全抽象层
我们并不建议你手工地把前面介绍的技术应用于每一个用户输入的实例中，而是强烈推荐你为此创建一个抽象层。一个简单的抽象是把你的校验方案加入到一个函数中，并且针对用户输入的每一项调用这个函数。当然，我们还可以创建一种更复杂的更高一级的抽象-把一个安全的查询封装到一个类中，从而应用于整个应用程序。在网上已经存在许多这种现成的免费的类；在本篇中，我们正要讨论其中的一些。
进行这种抽象至少存在三个优点（而且每一个都会改进安全级别）：
1. 本地化代码。
2. 使查询的构造更快且更为可靠-因为这可以把部分工作交由抽象代码来实现。
3. 当基于安全特征进行构建并且恰当使用时，这将会有效地防止我们前面所讨论的各种各样的注入式攻击。
二、 改进现有的应用程序
如果你想改进一个现有的应用程序，则使用一个简单的抽象层是最适当的。一个能够简单地"清理"你所收集的任何用户输入内容的函数可能看起来如下所示：
function safe( $string ) {
return "'" . mysql_real_escape_string( $string ) . "'"
}
【注意】我们已经构建了相应于值要求的单引号以及mysql_real_escape_string()函数。接下来，就可以使用这个函数来构造一个$query变量，如下所示：
$variety = safe( $_POST['variety'] );
$query = " SELECT * from wines WHERE variety=" . $variety;
现在，你的用户试图进行一个注入式攻击-通过输入下列内容作为变量$variety的值：
lagrein' or 1=1;
注意，如果不进行上面的"清理"，则最后的查询将如下所示（这将导致无法预料的结果）：
SELECT * from wines WHERE variety = 'lagrein' or 1=1;'
然而现在，既然用户的输入已经被清理，那么查询语句就成为下面这样一种无危害的形式：
SELECT * from wines WHERE variety = 'lagrein\' or 1=1\;'
既然数据库中不存在与指定的值相应的variety域(这正是恶意用户所输入的内容-lagrein' or 1=1;)，那么，这个查询将不能返回任何结果，并且注入将会失败。
三、 保护一个新的应用程序
如果你正在创建一个新的应用程序，那么，你可以从头开始创建一个安全抽象层。如今，PHP 5新改进的对于MySQL的支持（这主要体现在新的mysqli扩展中）为这种安全特征提供了强有力的支持（既有过程性的，也有面向对象特征的）。你可以从站点http://php.net/mysqli上获取有关mysqli的信息。注意，只有�
相关文档：
在SQL Server2005/2008中可以使用一下四个命令来调优sql语句以及检查调优的结果
set
statistics time on
set
statistics IO on
set
statistics profile on
set
statistics xml on
......
SQL语句优化实践之一SQL_TRACE
环境：在PL/sql上调试数据
Pl/sql developer工具连接实例后即作为一个用户进程占用一个session；
select * from v$session t where t.PROGRAM='plsqldev.exe' and t.USERNAME='DZJC'
查询结果显示了几个关键的字段
SADDR RAW(4) S ......
一、 注入式攻击的类型
可能存在许多不同类型的攻击动机，但是乍看上去，似乎存在更多的类型。这是非常真实的-如果恶意用户发现了一个能够执行多个查询的办法的话。本文后面，我们会对此作详细讨论。
如果你的脚本正在执行一个SELECT指令，那么，攻击者可以强迫显示一个表格中的每一行记录-通过把一个例如"1=1"这 ......
如何让你的SQL运行得更快(转贴)
---- 人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略
了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库
环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得� ......
