PHPCMS开发文档里看到PHP编码规范（5）

5.3.4. 查询优化

MySQL中并没有提供针对查询条件的优化功能，因此需要开发者在程序中对查询条件的先后顺序人工进行优化。例如如下的SQL语句：

SELECT * FROM table WHERE a>’0’ AND b<’1’ ORDER BY c LIMIT 10;

事实上无论a>’0’还是b<’1’哪个条件在前，得到的结果都是一样的，但查询速度就大不相同，尤其在对大表进行操作时。

开发者需要牢记这个原则：最先出现的条件，一定是过滤和排除掉更多结果的条件;第二出现的次之;以此类推。因而，表中不同字段的值的分布，对查询速度有着很大影响。而ORDER BY中的条件，只与索引有关，与条件顺序无关。

除了条件顺序优化以外，针对固定或相对固定的SQL查询语句，还可以通过对索引结构进行优化，进而实现相当高的查询速度。原则是：在大多数情况下，根据WHERE条件的先后顺序和ORDER BY的排序字段的先后顺序而建立的联合索引，就是与这条SQL语句匹配的最优索引结构。尽管，事实的产品中不能只考虑一条SQL语句，也不能不考虑空间占用而建立太多的索引。

同样以上面的SQL语句为例，最优的当table表的记录达到百万甚至千万级后，可以明显的看到索引优化带来的速度提升。

依据上面条件优化和索引优化的两个原则，当table表的值为如下方案时，可以得出最优的条件顺序方案：

字段a 字段b 字段c

1 7 11

2 8 10

3 9 13

-1 0 12

最优条件：b<’1’ AND a>’0’

最优索引：INDEX abc (b, a, c)

原因：b<’1’作为第一条件可以先过滤掉75％的结果。如果以a>’0’作为第一条件，则只能先过滤掉25％的结果

注意1：字段c由于未出现于条件中，故条件顺序优化与其无关

注意2：最优索引由最优条件顺序得来，而非由例子中的SQL语句得来

注意3：索引并非修改数据存储的物理顺序，而是通过对应特定偏移量的物理数据而实现的虚拟指针

EXPLAIN语句是检测索引和查询能否良好匹配的简便方法。在phpMyAdmin或其他MySQL客户端中运行EXPLAIN+查询语句，例如EXPLAIN select * FROM table WHERE a>’0’ AND b<’1’ ORDER BY c;这种形式，即使得开发者无需模拟上百万条数据，也可以验证索引是否合理，相关细节请参考MySQL说明。

值得提出的是，Using filesort是最不应当出现的情况，如果EXPLAIN得出此结果，说明数据库为这个查询专门建立了一个用以缓存结果的临时表文件，并在查询结束后删除。众所周知，硬盘I/O速度始终是计算机存储的瓶颈，因此，查询中应当尽全力避免高执行频率的SQL语句使用filesort。尽管，开发者永远都不可能保证产品中的全部SQL语句都不会使用filesort。

限于篇幅，本文档远远没有涵盖数据库优化的方方面面，例如：联合索引与普通索引的可重用性、JOIN连接的索引设计、MEMORY/HEAP表等。数据库优化实际上就是在很多因素和利弊间不断权衡、修改，惟有在成功与失败经验中反复推敲才能得出的经验，这种经验往往就是最难能可贵和价值连城的。

5.3.5. 兼容性问题

由于MySQL 3.23至5.0的变化很大，因此程序中尽量不使用特殊的SQL语句，以免带来兼容性问题，并给数据库移植造成困难。

通常在MySQL 4.1以上版本，phpcms应使用相当的字符集来存储，例如GBK/BIG5/UTF-8。传统的latin1编码虽然有一定的兼容性，但仍然不是推荐的选择。使用相应非默认字符集时，程序每次运行时需要使用SET NAMES ‘character_set’;来规定连接、传输和结果的字符集。

Mysql 5.0以上新增了数种SQL_MODE，默认的SQL_MODE依服务器安装设置不同而不同，因此程序每次运行时需要使用SET SQL_MODE=’’;来规定当前的SQL模式。

6. 模板设计

6.1.代码标记

HTML代码标记一律采用小写字母形式，杜绝任何使用大写字母的方式

模板中所有的逻辑体，如{if}、{loop}等，必须前后使用HTML注释(<!-- -->)，即类似<!--{if expr}-->的形式。事实上，phpcms模板编译器是支持不加HTML注释的逻辑体写法的，但加入注释可以使得模板可读性更好，同时方便用户使用DreamWeaver或FrontPage等对模板进行修改。