本章的内容主要讲解了如何给数据库的CURD查询添加回调事件，以及如何在最底层的SQL层面进行监听和做出性能分析及对查询性能做出优化建议，最后给出了一些安全方面的建议，学习内容主要从性能分析和优化，以及安全三个方面进行讲解：

• 性能分析
• 数据库调试模式
• 获取查询次数
• 获取SQL
• 开启性能分析
• SQL监听
• 性能优化
• SQL优化
• 字段缓存
• 数据缓存
• 模型缓存
• 查询事件
• 数据安全
• 底层防护
• 写入过滤
• 安全建议
• 总结

性能分析

除了一些糟糕的业务逻辑，框架的性能瓶颈一般都是在数据库（其它方面的性能没什么好纠结的）。业务逻辑的优化暂时不在本书的讨论范畴，我们首先来学习如何进行数据库的性能分析。

数据库调试模式

和应用的调试模式不同，数据库有自己独立的调试模式开关，在第一章我们已经提过，数据库配置参数中的debug参数就是数据库调试模式的开关。

// 数据库调试模式
'debug'           => true,

数据库调试模式开启后，可以支持下列行为：

• 记录SQL日志；
• 分析SQL性能；
• 支持SQL监听；

由于上述行为不可避免会产生额外的开销，因此对性能存在一定的影响，但并不大，因为所有的日志是最终统一一次性写入，而且可以设置为某个用户才写入日志。

在生产模式下面，必须关闭应用调试模式（app_debug），否则会暴露你的服务器敏感信息。和应用调试模式不同，开启数据库调试模式并不会对外暴露任何安全信息，因此是否开启数据库调试模式，看自己的需求。

获取查询次数

使用Db::getQueryTimes()方法可以获取当前的数据库查询次数，如果使用true作为参数的话可以获取包括写操作在内的查询次数。

// 获取读操作次数
$read = Db::getQueryTimes();
// 获取所有的查询次数
$count = Db::getQueryTimes(true);

如果开启了页面Trace显示的话，可以直观的看到当前请求的查询信息。

image

调用存储过程会被认为是执行一次查询操作而非写操作，尽管存储过程内部可能会有写入操作。

获取SQL

可以用getLastsql方法获取最后一次执行的SQL语句，无论是使用Db类还是模型类，所以下面的方式都是有效的：

Db::name('user')->where('id', '>', 0)->select();
echo Db::getLastSql();
$user = User::get(1);
echo $user->getLastsql();

getLastSql方法即使关闭数据库调试模式一样有效

如果使用了文件类型记录日志，并且开启了数据库调试模式的话，在日志文件中可以看到所有的SQL历史记录。

开启性能分析

框架不但能记录SQL日志，而且可以对查询的SQL语句作出性能分析，帮助你快速找出数据库性能瓶颈。

确保在数据库配置文件中开启下面两个参数：

        // 开启数据库调试模式
        'debug'           => true,
        // 开启SQL性能分析
        'sql_explain'     => true,

开启sql_explain参数后，会对查询的SQL做EXPLAIN解析（由每个连接器类的getExplain方法完成查询SQL分析），并把解析结果合并记录到SQL日志中（注意：目前仅对Mysql数据库有效）。

下面是一个查询的分析日志例子：

[ SQL ] SELECT * FROM `user` WHERE `id` IN (2) [ RunTime:0.000703s ]
[ EXPLAIN : array ( 'id' => 1, 'select_type' => 'SIMPLE', 'table' => 'think_user', 'partitions' => NULL, 'type' => 'system', 'possible_keys' => 'PRIMARY', 'key' => NULL, 'key_len' => NULL, 'ref' => NULL, 'rows' => 1, 'filtered' => 100.0, 'extra' => NULL, ) ]

SQL日志中会记录每个SQL的执行时间以及EXPLAIN分析结果，框架只是记录分析结果，至于如何查出问题和解决则需要你具备一定的SQL性能分析和优化知识。

当EXPLAIN分析结果中的extra中使用了filesort或者temporary的话，系统会额外记录一个警告错误告诉我们某条SQL存在性能问题需要处理。

SQL监听

如果觉得内置的性能分析不够全面，完全可以对执行的SQL进行监听并且对接第三方的SQL分析类库。使用listen方法注册SQL监听，例如可以在应用公共文件或者某个行为扩展中添加如下代码：

Db::listen(function ($sql, $time, $explain) {
    // 记录SQL
    Log::record($sql . ' [' . $time . 's]', 'sql');
    // 查看性能分析结果
    dump($explain);
});

如果关闭了sql_explain参数，explain参数就是一个空数组，你可以在监听方法中自行分析SQL性能问题。

监听的闭包方法支持传入三个参数，分别是：SQL语句、执行时间（秒）和性能分析结果（数组），并注意如下事项：

• 如果注册了多个SQL监听方法，则会依次调用；
• 一旦注册了SQL监听，则SQL日志和分析日志自动无效，由监听方法接管；

性能优化

现在我们已经基本掌握了性能分析的手段，那么如何进行性能优化（本书中的优化范畴主要是数据库操作层面的）就是摆在开发人员面前的一件棘手大事，如果是一般的应用可能主要做好数据表的索引就基本上没什么大的性能问题，对于大流量及高并发的应用，优化的手段和空间就比较多，因为这个情况下任何一个细小的优化都能带来可观的性能改进。

SQL优化

这里说的SQL优化主要针对数据库层面的优化，对于Mysql数据库来说，下面是一些比较常规的建议：

• 尽量少用SQL函数（会减少数据库自身查询缓存的命中率）而是用PHP变量传入；
• 给常用的查询字段建立索引或者联合索引；
• 对JOIN的条件字段建立索引，并且采用相同的数据类型（包括字符集）；
• 避免使用ORDER BY RAND()；
• 尽量调用field方法显式列出查询的字段，即使用field(true) ；
• 养成给数据表设置自增主键的习惯；
• 合理设计你的数据表字段类型；
• 对于大数据表使用垂直分表把数据表分为固定长度和不定长的两个表；

更深层次的优化可以对Mysql的配置参数进行优化配置（没有一劳永逸的配置优化，一定是针对应用场景的），相信大部分应用暂时还不需要到优化配置的地步，首先考虑的还是架构设计的优化，数据库配置的优化策略对应用的部署迁移会造成额外的成本以及不可预知的问题，如果你不是一个DBA角色不建议频繁调整配置参数。

字段缓存

说完了数据库层面的优化，我们后面着重来说下框架和应用层面的优化。

为了更安全的进行数据库操作，框架底层在查询数据表数据的时候，会首先获取该数据表的字段信息，包括字段名称、字段类型以及主键名，对于不在字段列表中的字段则会进行忽略处理甚至抛出异常，字段类型则用于进行写入和查询的自动参数绑定，虽然说每个数据表只会获取一次字段信息，但每次请求都要重新获取一次不免觉得有点性能浪费。不过在开发阶段，如果经常会涉及到字段信息的变化，还是无所谓，但如果已经部署上线了的话，还是建议使用字段缓存，也可以有效提高查询性能，我们会在页面Trace的SQL栏中看到类似的信息

[ SQL ] SHOW COLUMNS FROM `user` [ RunTime:0.001582s ]

其实就是查询数据表user的字段信息的SQL语句（不同的数据库查询字段信息的SQL语句是不同的，由连接器类的getFields方法完成查询）。

部署上线后，可以在命令行下执行以下指令生成字段缓存，在命令行切换到应用的根目录（think文件所在目录），输入：

php think optimize:schema

会自动生成当前数据库配置文件中定义的数据表字段缓存，执行后会自动在runtime/schema目录下面按照数据表生成字段缓存文件，缓存文件的命名格式为：

数据库名.数据表名.php

如果你的应用有多个数据库的操作，也可以指定数据库生成字段缓存（必须有用户权限），例如，下面用--db参数指定生成demo数据库下面的所有数据表的字段缓存信息。

php think optimize:schema --db demo

如果你的应用不同的模块使用了不同的数据库连接，还可以根据模块来生成，用--module参数指定模块如下：

php think optimize:schema --module index

会读取index模块的模型来生成数据表字段缓存，没有继承think\Model类的模型和抽象类不会生成。

每次执行指令都会重新生成数据表字段缓存文件，如果只是更改了数据表的某个字段或者增加了新的字段，重新部署上线的时候，支持单独更新某个数据表的缓存。

使用 --table参数指定需要更新的数据表：

php think optimize:schema --table user

支持指定数据库名称

php think optimize:schema --table demo.think_user

生成字段缓存后，你会发现数据库的查询性能提升明显，尤其是在请求中操作大量数据表的情况下。

数据缓存

数据库的优化手段有时候比不过架构和缓存的设计优化，而架构的优化是一个综合的范畴，需要针对具体的逻辑和场景，并且优化的手段通常多元化，模型关联的设计也是底层提供的架构设计的优化手段之一（使用预载入查询可以有效减少数据库查询次数），现在我们要讲的是如何利用数据缓存策略来减少数据库的查询开销，这是一个不依赖数据库的普适优化策略。

数据库的数据缓存并不是你理解的直接使用Cache类进行操作，那样太麻烦了，每次都要手动设置及额外读取，也许像下面这样：

$user = Cache::get('user_cache');
if (!$user) {
    $user = Db::table('user')
        ->where('id', 10)
        ->find();
    Cache::set('user_cache', $user);
}

查询类封装了一个数据缓存的链式方法cache，可以很方便的进行查询数据的自动缓存和读取，以及缓存数据的自动更新。数据库的缓存策略主要就是掌握cache链式方法的使用，下面我们仔细给你讲解下用法。

先给出一个最简单的用法：

Db::table('user')
    ->cache(600)
    ->where('id', 10)
    ->find();

Db::table('user')
    ->where('status', 1)
    ->cache(600)
    ->count();

可以对find、select、value和column方法及其衍生方法使用数据缓存功能，不支持原生查询query方法。

cache方法如果传入数字，表示查询数据的缓存时间（秒），所以上面的查询在10分钟以内多次调用的话不会重复查询数据库，而是直接读取缓存数据（使用当前配置的缓存类型和缓存参数）。

如果需要在外部调用缓存数据（尽管并不常见，但在跨模块的时候可能会需要），可以指定缓存标识，例如：

Db::table('user')
    ->cache('user_cache_key', 600)
    ->where('id', 10)
    ->find();

cache方法的第一个参数使用字符串表示缓存标识，这个时候第二个参数就表示缓存有效期，然后可以在外部调用缓存的用户数据：

// 缓存数据有效期为10分钟
$userData = Cache::get('user_cache_key');

内置的数据缓存策略对原生查询不起作用（只能单独使用缓存方法来进行缓存），相比缓存的优势用原生查询的那点性能优越感这个时候已经荡然无存了，查询构造器的优势就很明显了。

数据缓存策略的关键是如何及时更新缓存数据，我们来看下如何做到自动更新缓存，下面的内容才是数据缓存要讲的关键。

只需要在调用更新或者删除方法之前调用cache方法（见证奇迹的时刻到了）：

Db::table('user')
    ->cache('user_data')
    ->select([1, 3, 5]);

Db::table('user')
    ->cache('user_data')
    ->update(['id' => 1, 'name' => 'thinkphp']);

Db::table('user')
    ->cache('user_data')
    ->select([1, 3, 5]);

在更新数据的时候调用cache手动清除缓存，所以最后查询的数据不会受第一条查询缓存的影响，查询出来的数据依然是同步更新后的数据。

同样，如果进行了删除操作，也会自动清除缓存数据。

Db::table('user')
    ->cache('user_data')
    ->select([1, 3, 5]);

Db::table('user')
    ->cache('user_data')
    ->delete(1);

Db::table('user')
    ->cache('user_data')
    ->select([1, 3, 5]);

确保查询和更新或者删除使用相同的缓存标识才能自动清除缓存。

比较常用的数据缓存是以主键为查询条件的单个数据的缓存，所以如果使用find方法并且使用主键查询的情况，缓存更新更智能。update或者delete方法可以不需要调用cache方法，也会自动清理缓存，例如：

Db::table('user')
    ->cache(true)
    ->find(1);

Db::table('user')
    ->update(['id' => 1, 'name' => 'topthink']);

Db::table('user')
    ->cache(true)
    ->find(1);

根据主键查询的话，缓存更新是自动的，因此上面的例子最后查询的数据会是更新后的数据。

使用where方法查询主键条件的话，效果一样：

Db::table('user')
    ->cache(true)
    ->where('id', 1)
    ->find();

Db::table('user')
    ->where('id', 1)
    ->update(['name' => 'topthink']);

Db::table('user')
    ->cache(true)
    ->where('id', 1)
    ->find();

模型缓存

除了使用Db类，模型类还提供了更方便的方法进行数据缓存。如果是缓存读取单个数据，可以使用：

// 查询数据并缓存读取
$user = User::get(1, [], true);
// 设置缓存有效期
$user = User::get(1, [], 600);

由于第二个参数是预载入查询，所以查询缓存屈居二线了^_，不过如果你的版本在5.0.6以上的话，可以直接写成：

// 查询数据并缓存读取
$user = User::get(1, true);
// 设置缓存有效期
$user = User::get(1, 600);

当使用主键查询、更新和删除模型数据的时候，会自动更新模型数据缓存。如果你的查询条件不是主键，可以指定缓存标识，并在删除的时候带上缓存标识，例如：

// 查询name为thinkphp的用户数据并缓存读取
$user = User::cache('user_key_thinkphp')
    ->getByName('thinkphp');
// 删除数据并更新缓存数据
$user->cache('user_key_thinkphp')
    ->delete();

模型数据缓存标识不能直接在外部读取，因为缓存的数据都是数组而不是对象，所以下面才是正确的姿势。

// 查询name为thinkphp的用户数据并缓存读取
$user = User::cache('user_key_thinkphp')
    ->getByName('thinkphp');
// 外部读取模型数据缓存
$data = new User(Cache::get('user_key_thinkphp'));

同样的用法，如果要缓存读取多个数据，使用下面的方式：

// 查询多个数据并缓存读取
$users = User::all([1, 2, 3], [], true);
// 设置缓存有效期
$users = User::all([1, 2, 3], [], 3600);

5.0.6版本以上同样可以使用

// 查询多个数据并缓存读取
$users = User::all([1, 2, 3], true);
// 设置缓存有效期
$users = User::all([1, 2, 3], 3600);

模型的数据缓存配合关联预载入查询的话效果更佳，关于如何使用关联预载入查询请参考上一章的内容。

查询事件

使用查询事件可以在不改变原有数据查询代码的前提下制定独立的缓存策略，先来了解下什么是查询事件。

查询事件是针对数据库的CURD操作而设计的回调方法，主要包括：

使用下面的方式注册一个查询事件

Db::event('before_select', function ($options, $query) {
    // 事件处理
});

如果before_select或者before_find回调方法有返回数据，则表示提前返回查询结果，不会继续执行查询操作。

Db::event('before_find', function ($options, $query) {
    // 事件处理
    if ('user' == $options['table']) {
        $result = ['id' => 1, 'name' => 'thinkphp'];
        return $result;
    }
});

$user = Db::table('user')->find();

user变量最终的结果是['id'=>1,'name'=>'thinkphp']。

下面的例子我们没有使用cache方法进行数据缓存，而是利用查询事件来定制自己的数据缓存策略。

// after_insert回调方法
Db::event('after_insert', function ($options, $query) {
    $pk   = $query->getPk($options);
    $guid = $options['table'] . '_' . $options['data'][$pk];
    Cache::set($guid, $options['data'], 0);
});

// after_update回调方法
Db::event('after_update', function ($options, $query) {
    $pk   = $query->getPk($options);
    $guid = $options['table'] . '_' . $options['data'][$pk];
    $data = Cache::get($guid);
    $data = array_merge($data, $options['data']);
    Cache::set($guid, $data, 0);
});

// after_delete回调方法
Db::event('after_delete', function ($options, $query) {
    $pk   = $query->getPk($options);
    $guid = $options['table'] . '_' . $options['data'][$pk];
    Cache::set($guid, null, 0);
});

// before_find回调方法
Db::event('before_find', function ($options, $query) {
    $pk   = $query->getPk($options);
    $guid = $options['table'] . '_' . $options['data'][$pk];
    $data = Cache::get($guid);
    if ($data) {
        return $data;
    }
});

注册完查询回调方法后，下面的查询除了写操作会执行数据库操作，其它的查询方法都直接读取缓存数据，而且始终保持最新的数据。

$id = Db::table('user')
    ->insert(['name'=>'thinkphp']);

Db::table('user')->find($id);

Db::table('user')
    ->where('id',$id)
    ->update(['name'=>'topthink']);

Db::table('user')->find($id);

Db::table('user')
    ->delete($id);

Db::table('user')->find($id);  

数据安全

安全和优化就如同鱼和熊掌一般，很难兼得。从某种程度上说，数据安全比性能优化更重要，因此为了更加安全和稳健运行，牺牲一定的性能都是值得的，下面我们来学习下基本的安全策略。

底层防护

5.0版本提供了更高的底层安全策略，虽然不至于因此而高枕无忧，但也完全不必杞人忧天，主要体现在：

• WEB访问目录和应用目录隔离；
• 内置使用PDO预处理和自动参数绑定机制；
• 默认用户提交数据不支持数组；
• 支持数据自动过滤机制；

只要善于运用系统提供的安全手段和做好一些配置，可确保你的应用安全无虞，听我给你细细道来。

写入过滤

由于系统的安全机制，任何非数据表的字段如果要写入数据库都会导致异常，如果你不希望非数据表字段写入数据库的时候抛出异常，而只是忽略就行，那么可以使用下面两种方式。

如果是仅仅当前操作忽略，则可以使用strict方法，例如：

Db::table('user')
    ->strict(false)
    ->insert([
        'name'     => 'thinkphp',
        'nickname' => '流年',
        'test'     => '测试数据',
    ]);

由于user表中并不存在test字段，因此test数据会被直接忽略，但由于使用了strict(false)方法，而不会抛出异常。

如果希望全局不抛出异常，可以在数据库配置文件中设置

        // 是否严格检查字段是否存在
        'fields_strict'   => false,

但有些时候我们还需要限制写入数据库的字段，避免被用户提交更新一些敏感数据，并非只有查询的时候可以使用field方法指定字段列表，我们还可以在写入数据的时候使用field方法限制字段写入。

Db::table('user')
    ->field('name,nickname')
    ->where('id', 1)
    ->update([
        'name'     => 'thinkphp',
        'nickname' => '流年',
        'email'    => 'thinkphp@qq.com',
    ]);

上面的例子中，由于我们用field方法限制了写入的字段列表，因此email数据不会被更新，而是直接忽略。

同样，field方法也支持排除某些字段

Db::table('user')
    ->field('email,score', true)
    ->where('id', 1)
    ->update([
        'name'     => 'thinkphp',
        'nickname' => '流年',
        'email'    => 'thinkphp@qq.com',
    ]);

如果使用模型操作的话，我们还可以使用allowField方法提前对数据进行字段过滤

$user           = User::get(1);
$user->name     = 'thinkphp';
$user->nickname = '流年';
$user->email    = 'thinkphp@qq.com';
$user->allowField('name,nickname')
    ->save();

allowField过滤数据并不会导致异常，和field方法不同，allowField方法并不支持字段排除，如果调用allowField(true) 表示过滤数据表字段之外的数据

模型还额外提供了一个只读字段的功能，针对某些字段只提供写入功能而不提供更新功能，具体可以参考模型高级用法一章的内容。

安全建议

为了让你的应用更安全，综合之前提到的各种安全因素，在数据库的层面我们给出如下安全建议：

• 对用户输入的数据做尽可能的验证；
• 对写入的数据做好过滤，避免异常；
• 避免直接使用用户提交数据作为查询条件；
• 查询字段名不应该由表单或者用户决定；
• 对于get和find方法的参数建议做好Null判断；
• 数据输出的时候注意做好XSS安全过滤；
• 对于模型数据尽量隐藏敏感数据后输出；
• 对于业务数据的写入操作应当做好权限检查；
• 写入数据严格使用field方法限制写入字段；

举个例子，如果你开放查询字段名给用户提交而未作判断直接作为查询条件，例如下面的代码：

$where = request()->param();
// 查询用户是否存在
$user = Db::table('user')
    ->where($where)
    ->find();

假设你的表单里面有一个name字段，那么，用户就可以在浏览器构造一个name|email字段完成OR查询，查询的结果可能完全不同了，极有可能造成逻辑漏洞。

正确的查询方式应该是：

// 查询用户是否存在
$user = Db::table('user')
    ->where('name',request()->param('name'))
    ->find();

总结

到目前为止，我们已经完成了5.0的数据库和模型的学习，最好的老师是实践并把掌握的知识点融会贯通，在后面的附录中我们会给大家汇总整理一些常见问题，并保持不断更新。

感谢你坚持看完了本书的内容，您的建议是我们努力完善的动力，希望不吝赐教并随时在本书的评论区或者github上给我们留言，最后祝你在新的开发征程中所向披靡，因为我们的愿景就是让开发变得更简单！

上一篇：第八章：模型关联
下一篇：附录A：常见问题