C1G军火库

Error : Unknown column ‘j.cid’ in ‘on clause’
Errno : 1054
select j.*,jf.jid,jf.pid,jf.man,m.cid as comid,m.company from wane_comjobs j,wane_comjobs_fields jf left join wane_member_comfields m on (j.cid=m.cid) where j.jid=jf.jid

语句在4.0上可以跑,看文档在5.1上也能跑,在5.0上跑时需将要连接的表放在右边。

如
SELECT j. * , jf.jid, jf.pid, jf.man, m.cid AS comid, m.company
FROM wane_comjobs j,wane_comjobs_fields jf
LEFT JOIN wane_member_comfields m ON ( j.cid = m.cid )
WHERE j.jid = jf.jid

大家在写sql 语句的时候， 如果是 select .. where 类型的语句， 有注意到条件的前后顺序吗？我今天做个小实验。
比如查询地址里 包含“海口市”及“振兴路” 两个关键字的数据， 一般时候可能会用
select * from dm_addr where addr like ‘%海口市%’ and addr like ‘%振兴路%’ 的形式，但其实这种查询效率不高，原因在于条件的前后顺序。以下是测试结果

mysql> select count(1) from dm_addr where addr like ‘%振兴路%’ and addr like ‘%海口市%’;
+———-+
| count(1) |
+———-+
| 96 |
+———-+
1 row in set (0.82 sec)

mysql> select count(1) from dm_addr where addr like ‘%海口市%’ and addr like ‘%振兴路%’;
+———-+
| count(1) |
+———-+
| 96 |
+———-+
1 row in set (0.91 sec)

我做了很多次查询
where addr like ‘%海口市%’ and addr like ‘%振兴路%’ 总是比 where addr like ‘%振兴路%’ and addr like ‘%海口市%’
慢，原因是查询是先处理第一条件，然后在处理第二个条件，先查询出所有 包含“海口市”的记录，再在这些记录中查询包含”振兴路” 的记录。 对于地址情况， 包含“海口市”的记录可能大于”振兴路” 的记录，我做测试的表有2万条数据， 已经有大概0.1s的差别。如果碰到大数据，这个差别会更大。
按以上的分析结果， 我们写SQL语句的时候， 对于select …where … 类型的语句，应该把查询结果范围小的条件放在前面，查询范围大的条件放在后面，这样会提高效率。

对于OR的情况：
测试如下：

mysql> select count(1) from dm_addr where addr like ‘%海口市%’ or addr like ‘%振兴路%’;
+———-+
| count(1) |
+———-+
| 39168 |
+———-+
1 row in set (0.84 sec)
mysql> select count(1) from dm_addr where addr like ‘%振兴路%’ or addr like ‘%海口市%’;
+———-+
| count(1) |
+———-+
| 39168 |
+———-+
1 row in set (0.95 sec)

OR语句的处理过程是这样， 对于每一条地址， 逐个分析条件，如果符合第一个条件，就不做第二条件的判断，那么我们应该把容易做判断的条件放在前面， 比如查询地址里 包含“海口市”或“振兴路” 个关键字的数据，按地址一般排法，XX市应该在XX路前。所以如果用第一种方式，那就效率高，判断有海口市就可以确认这行地址有效了。 所以在写OR类型的条件时， 应该把容易判断的条件写在前面。

再做一个NOT … OR .. NOT … 测试，查询不包含 海口市 或者不包含 振兴路 的数据
mysql> select count(1) from dm_addr where addr not like ‘%海口市%’ or addr not like ‘%振兴路%’;
+———-+
| count(1) |
+———-+
| 38752 |
+———-+
1 row in set (0.92 sec)

mysql> select count(1) from dm_addr where addr not like ‘%振兴路%’ or addr not like ‘%海口市%’;
+———-+
| count(1) |
+———-+
| 38752 |
+———-+
1 row in set (0.86 sec)

因为每条数据都有海口市， 所以对于第一个查询，判断第一个条件都失败了， 都需要判断第二个。
对于第二个查询， 只要判断第一个条件为真就可以确定这个记录， 不需要判断第一个条件，
所以第二个查询效率高过第一个。

结论：对于select … where … 类型的语句。
对于OR条件， 需要把命中率高的条件放在前面。
对于AND条件，需要把条件限制范围小的条件放在前面。
希望这些实验能提高phper 的程序效率。以上测试是对于mysql 5.0 win 做的。好象记得ORACLE刚好相反， 是先判断最后的条件。

php 里查询汉字的拼音首字母已经有很多参考的代码了。
现在给出在mysql 里实现的， 测试环境是mysql-5.0.27-win32

1、建立拼音首字母资料表

2、建立mysql 函数

3、先测试一下
mysql> select hzcode(’南海龙王’);
+——————–+
| hzcode(’南海龙王’) |
+——————–+
| N |
+——————–+
1 row in set (0.00 sec)

4、建立个测试表

5、测试

mysql> select * from f1;
+——+——-+
| name | pykey |
+——+——-+
| 张三 | NULL |
| 李四 | NULL |
| 王五 | NULL |
| 赵六 | NULL |
| 钱七 | NULL |
+——+——-+
5 rows in set (0.00 sec)

mysql> update f1 set pykey = hzcode(name);
Query OK, 5 rows affected (0.05 sec)
Rows matched: 5 Changed: 5 Warnings: 0

mysql> select * from f1;
+——+——-+
| name | pykey |
+——+——-+
| 张三 | Z |
| 李四 | L |
| 王五 | W |
| 赵六 | Z |
| 钱七 | Q |
+——+——-+
5 rows in set (0.00 sec)

这样就很方便地在MYSQL里查询汉字的首字母了。 类似地也可以直接在MYSQL得到汉字拼音。 不过需要拼音表，函数写法也不一样。

web安全色，又叫做网页安全色或者网络安全色。其实色彩和安全本没有关系，但是如果网页设计师做出来的图形用户看不到最佳的效果，那么对设计师来说，工作就不太安全了。也许“安全”就是这个意思吧。

大家都直到的是，web安全色是历史遗留问题。在计算机刚刚开始设计生产的年代，不同厂商、国家生产的产品都有不通的规范和标准，因为没有网络，所以也就不涉及到兼容的问题。那时候的机型泛滥，不通的机型也必须搭配不同的系统软件。后来促使计算机生产标准统一的，大概又两个主要因素。一个是计算机的普及，硬件和软件的兼容流通；再一个是互联网的产生，计算机要联在一起，当然需要共同的协议和标准。在这样的背景下，一些计算机生产标准被淘汰，一些标准重新开发。不同的标准趋于接近甚至统一。到了今天，我们常见的计算机就是PC和MAC。前者是以英特尔和微软等软硬件厂商为代表，后者主要的产品供应商是苹果公司。目前也有其它的厂商小规模的生产其它标准的主机，如惠普和IBM等，产品大都以服务器为主，不属于互联网的终端。

我们把目光还是折回当年。不同的终端标准，作为主要输出设备的显示器，它的等级和种类是不同的，能够显示出的色彩也就不同。另外，不同的操作系统的色彩系统也不同。这样就导致用A终端做出来的网页色彩，用B终端就看不到。好在几乎所有的显示设备和操作系统都能够正确显示其中216种色彩，那么这些色彩就是网页上的安全色。

win和mac的色彩系统都是由256中色彩组成，如果再仔细研究，就能找到其中共同的216中色彩，就是web安全色了。

web216安全色并不是没有规律的巧合。无论是哪个厂家生产的系统和显示设备，都要遵循数字色彩的显示规律，这就是RGB数字色彩显示模式。自然界的色彩种类是无穷尽的，但是计算机的只能有限、离散的显示色彩。

关于RGB色彩模式这里就不展开说明了，只要知道，在该模式下的色彩，都由R（红）、G（绿）、B（蓝）三种基本色彩混合而成。每重基本色彩根据发光强弱而分成若干级别，称为色阶。色阶越多，RGB色彩空间所包含的色彩也就越多。我们常用的24位真彩色模式下，各个基本色彩的色阶为256（28），则R、G、B混合得到的色彩数目为256×256×256=16777216=224。这也是目前主流显示器能显示的最大色彩数目。

过去的终端也是用RGB的模式显示色彩，只是达不到24位的色彩数目，多数只能显示256种色彩（有写朋友对256色比较迷信，认为是固定的色彩，非也；也有人认为web安全色是256，原因就再这里）。那么是哪256种色彩呢？这就不一定了。因为256不是某个数值的3次方能够得到的，而是介于63（216）和73（343）之间，因此，在选择256种色彩的时候，就有两种办法：第一，RGB各分6个色阶，这样有216种色彩，再另外选择40种色彩凑成256色；第二，RGB各分7个色阶，这样有343种色彩，再去掉87种色彩。比较一下，可以看出，还是第一种方法更加简便直接。因此广为采用。256种色彩中余下的40种色彩不同的厂商采取了不同的选择方式。而216种色彩却是相同方式选择的。

很明显，这216色是24位色彩空间的子集。我们用三个数字连在一起表到24位RGB色彩，那么十进制是255，255，255的形式，十六进制就是FFFFFF的形式。前面说了216色每个基色是6个色阶，如果将256个色阶均分，就是0，51，102，153，204，255这六个数字，换算成十六进制即：00，33，66，99，CC，FF，因此216色就是将这六个数字进行任意排列组合的到的。

因此，web安全色并非偶然，这是由必然的规律做出的选择。