嗯，KEY `uid` (`c_uid`)的确是重复索引了，我的意思是表中有多个字段不确定是单个查询排序或者多个字段组合查询排序，在这样的情况下是为每个字段单独建立索引，还是根据查询语句顺序排列好建立复合索引效率高？复合索引的话必须按照顺序构建查询语句，如果查询条件增加或缩小的情况是否索引会失效，表中建立太多个单字段索引是否会影响效率？我的意思是表中有多个字段不确定是单个查询排序或者多个字段组合查询排序 这种情况下你需要自己先列出所有可能的查询，然后为所有这些查询配置索引，再把重复的索引去除。在这样的情况下是为每个字段单独建立索引，还是根据查询语句顺序排列好建立复合索引效率高？ 各有优缺点，要看具体情况，脱离了具体情况下结论就是胡说八道了。如果查询条件增加或缩小的情况是否索引会失效 或者会，或者不会，要看具体。如果有兴趣你可以看一下MYSQL官方免费手册中的优化那个章节中对索引的分析讨论。未必会索引失效，有特例。表中建立太多个单字段索引是否会影响效率？ 无从结论，要看楼主所谓的效率是什么。查询上没什么差别。插入上会有所影响。数据量100万的情况下方案1：KEY `paixu` (`hits`,`good`,`bad`,`comment`) /*[13:52:00][ 47 ms]*/ SELECT COUNT(id) FROM joke WHERE hits>188 AND good>120 AND bad>5 ; /*[13:55:23][ 127 ms]*/ SELECT COUNT(id) FROM joke WHERE good>12 AND bad>5 ;方案2：KEY `hits` (`hits`), KEY `good` (`good`), KEY `bad` (`bad`), KEY `comment` (`comment`) /*[13:52:18][ 47 ms]*/ SELECT COUNT(id) FROM joke2 WHERE hits>188 AND good>120 AND bad>5 ; /*[13:55:23][ 47 ms]*/ SELECT COUNT(id) FROM joke2 WHERE good>12 AND bad>5 ;上面两种索引方案查询 hits + good +bad 的时候效率应该一样，但是方案1只查询 good + bad 或者 bad 的时候好像就没有用到索引，像这种情况不知是为每个字段单独索引还是复合索引，看网上的资料说多个字段查询复合索引效率更高
KEY `paixu` (`hits`,`good`,`bad`,`comment`) /*[13:52:00][ 47 ms]*/ SELECT COUNT(id) FROM joke WHERE hits>188 AND good>120 AND bad>5 ; /*[13:55:23][ 127 ms]*/ SELECT COUNT(id) FROM joke WHERE good>12 AND bad>5 ; 这种情况下 第二个语句是没办法用到索引的 如果你要验证复合索引的效率，此时应该建立index（good，bad）
楼主最好能够预计下会用什么查询，然后explain分析下。 另外：建立了复合索引，并不是用了里面的字段查询就会用到索引，必须按照顺序来，单独抽中间一个字段是不会用到索引的 比如建立复合索引cc KEY `cc` (`dd`,`aa`) USING BTREE 那么语句： select * from test where dd=5 -----有用到索引 select * from test where aa=5 ------没有用到索引
嗯，KEY `uid` (`c_uid`)的确是重复索引了，我的意思是表中有多个字段不确定是单个查询排序或者多个字段组合查询排序，在这样的情况下是为每个字段单独建立索引，还是根据查询语句顺序排列好建立复合索引效率高？复合索引的话必须按照顺序构建查询语句，如果查询条件增加或缩小的情况是否索引会失效，表中建立太多个单字段索引是否会影响效率？
嗯，KEY `uid` (`c_uid`)的确是重复索引了，我的意思是表中有多个字段不确定是单个查询排序或者多个字段组合查询排序，在这样的情况下是为每个字段单独建立索引，还是根据查询语句顺序排列好建立复合索引效率高？复合索引的话必须按照顺序构建查询语句，如果查询条件增加或缩小的情况是否索引会失效，表中建立太多个单字段索引是否会影响效率？我的意思是表中有多个字段不确定是单个查询排序或者多个字段组合查询排序
这种情况下你需要自己先列出所有可能的查询，然后为所有这些查询配置索引，再把重复的索引去除。在这样的情况下是为每个字段单独建立索引，还是根据查询语句顺序排列好建立复合索引效率高？
各有优缺点，要看具体情况，脱离了具体情况下结论就是胡说八道了。如果查询条件增加或缩小的情况是否索引会失效
或者会，或者不会，要看具体。如果有兴趣你可以看一下MYSQL官方免费手册中的优化那个章节中对索引的分析讨论。未必会索引失效，有特例。表中建立太多个单字段索引是否会影响效率？
无从结论，要看楼主所谓的效率是什么。查询上没什么差别。插入上会有所影响。
嗯，KEY `uid` (`c_uid`)的确是重复索引了，我的意思是表中有多个字段不确定是单个查询排序或者多个字段组合查询排序，在这样的情况下是为每个字段单独建立索引，还是根据查询语句顺序排列好建立复合索引效率高？复合索引的话必须按照顺序构建查询语句，如果查询条件增加或缩小的情况是否索引会失效，表中建立太多个单字段索引是否会影响效率？我的意思是表中有多个字段不确定是单个查询排序或者多个字段组合查询排序
这种情况下你需要自己先列出所有可能的查询，然后为所有这些查询配置索引，再把重复的索引去除。在这样的情况下是为每个字段单独建立索引，还是根据查询语句顺序排列好建立复合索引效率高？
各有优缺点，要看具体情况，脱离了具体情况下结论就是胡说八道了。如果查询条件增加或缩小的情况是否索引会失效
或者会，或者不会，要看具体。如果有兴趣你可以看一下MYSQL官方免费手册中的优化那个章节中对索引的分析讨论。未必会索引失效，有特例。表中建立太多个单字段索引是否会影响效率？
无从结论，要看楼主所谓的效率是什么。查询上没什么差别。插入上会有所影响。数据量100万的情况下方案1：KEY `paixu` (`hits`,`good`,`bad`,`comment`)
/*[13:52:00][ 47 ms]*/ SELECT COUNT(id) FROM joke WHERE hits>188 AND good>120 AND bad>5 ;
/*[13:55:23][ 127 ms]*/ SELECT COUNT(id) FROM joke WHERE good>12 AND bad>5 ;方案2：KEY `hits` (`hits`),
KEY `good` (`good`),
KEY `bad` (`bad`),
KEY `comment` (`comment`)
/*[13:52:18][ 47 ms]*/ SELECT COUNT(id) FROM joke2 WHERE hits>188 AND good>120 AND bad>5 ;
/*[13:55:23][ 47 ms]*/ SELECT COUNT(id) FROM joke2 WHERE good>12 AND bad>5 ;上面两种索引方案查询 hits + good +bad 的时候效率应该一样，但是方案1只查询 good + bad 或者 bad 的时候好像就没有用到索引，像这种情况不知是为每个字段单独索引还是复合索引，看网上的资料说多个字段查询复合索引效率更高
/*[13:52:00][ 47 ms]*/ SELECT COUNT(id) FROM joke WHERE hits>188 AND good>120 AND bad>5 ;
/*[13:55:23][ 127 ms]*/ SELECT COUNT(id) FROM joke WHERE good>12 AND bad>5 ;
这种情况下 第二个语句是没办法用到索引的 如果你要验证复合索引的效率，此时应该建立index（good，bad）
另外：建立了复合索引，并不是用了里面的字段查询就会用到索引，必须按照顺序来，单独抽中间一个字段是不会用到索引的
比如建立复合索引cc
KEY `cc` (`dd`,`aa`) USING BTREE
那么语句：
select * from test where dd=5 -----有用到索引
select * from test where aa=5 ------没有用到索引