Navicat
bitsCN.com索引的目的是大大提高查询效率，还有读写效率。
kettle向sql里面插入，更新时，也要建立索引，可以大大提升处理时间。
但是建立索引报错：Specified key was too long; max key length is 1000 bytes
这是mysql中，索引字段的类型设置的总体过长，看一下fields里面字段类型，总体加起来不超过1000字节
注意，字段长度，是char长度乘以自身字段类型的位数，累加和不能超过限定的key长1000：
latin1 = 1 byte = 1 character
uft8 = 3 byte = 1 character
gbk = 2 byte = 1 character
以GBK为例：
CREATE UNIQUE INDEX `unique_record` ON reports (`report_name`, `report_client`, `report_city`);
其中report_name varchar(200), report_client varchar(200), report_city varchar(200)
(200 + 200 +200) * 2 = 1200 > 1000，就会报1071错误，只要将report_city改为varchar(100)那么索引就能成功建立。
但如果表是UTF8字符集，那索引还是建立不了，因此要乘以3。
用 php + mysql 驱动的在线商城系统，我们的目标为中国的中小企业及个人提供最简洁，最安全，最高效的在线商城解决方案，使用了自建的会员积分折扣功能，不同的会员组有不同的折扣，让您的商店吸引更多的后续客户。 系统自动加分处理功能，自动处理会员等级，免去人工处理的工作量，让您的商店运作起来更方便省事 采用了自建的直接模板技术，免去了模板解析时间，提高了代码利用效率 独立开发的购物车系统，使用最
KEY `idx_1` (`packagename`,`storename`,`app_name`,`version`,`category`,`app_link_hash`) USING BTREE
字段类型都是utf8，乘3后，超过1000。
我建的表，字段长度超了，而数据不能动，所以就用了一下小技巧：
1，applink字段要200以上，用了必超。解决办法：将applink用MD5算法，转换为特定长度的applink_hash码（32位长），一一对应，长度特定，用这个新字段只有32位就行了。排除过长字段，转换成特定hashcode，一一对应。
2，kettle插入时分析唯一key。字段之间关系，很多字段联合起来可以唯一确定某个字段，那这个字段就不用出现在索引中。kettle插入时就不用去比对这个字段
3，改成小字段的兼容类型。如果字段内容，允许，也就是包含的内容，很少，比如utf8的类型，可以修改成gbk，就可以省去一个字段。但是数据内容必须能被gbk包含，否则，内容不识别，插进去也没用。
bitsCN.com
