【求助】表A记录1万，表B记录10万，如果COUNT 更快？每次只能100个也还是很慢

Question

本帖最后由 default7 于 2012-03-02 10:03:14 编辑

Answer 1

 `content` LIKE '%$wd%'
这个比较难受 有索引的话也基本上很难会去走

Answer 2

%$wd%:无法用到索引
content id上建立索引没有

Answer 3

表A字段id设置的是主键，自动递增。索引未设置，唯一未设置。
表B字段content，类型text。主键未设置、索引未设置、唯一未设置。因为B表每天的数据是以1万递增的，每天递增的数据大小是20MB左右。
如果设置表B的字段content为【索引】会不会很占空间影响查询速度？而且好像有一个【全文检索】的设置的，这个是不知道可否用上 如何用

Answer 4

关键是这个`content` LIKE '%$wd%' 根本无法使用索引，也就是说，每次查询，都需要把表中的所有记录都遍历一遍。

Answer 5

"SELECT COUNT(*) FROM B WHERE `content` LIKE '%$wd%' " 无法利用到索引;优化下count(tid)吧

Answer 6

反过来呢，不是A表查B表，而是B表添加的时候，去更新A表。呵呵，不太懂，随意发表一下自己的想法哈。

Answer 7

这样不太好。
A表更新频率是大约几天会才会有新增或删减。
B表是每1分钟内就会有数个更新或者删减。
如果B表每隔1分钟就刷新A表数次，那样会很占服务器CPU的。

Answer 8

 like "%WD%" 中的WD是不是固定值，如果是的话试一下instr函数索引。

Answer 9

LZ可以搜索下instr函数与like的。数据量越大，提升越明显
  我在大数据量模糊查询的时候就是用的instr函数

Answer 10

你这自检程序就只能增加数据库的压力；一但数据量上来了，后果将会很严重。只有从自检程序入手才能有效的解决问题。你的自检程序可以定时运行，比如每天晚上0点运行；统计前一天的数据的增加，删除情况，然后更新数量。这样比你一次like数10万的数据要快很多。只是个建议很多时候，一个好的设计就可以减轻服务器很大的压力。

Answer 11

A表才1万条，全部加到内存中吧；然后B更新的时候更新一下A中的数据，并保持和库的同步。

Answer 12

一个贴吧 一个独立处理单元（可以分目录，分表,分端口，分服务器...etc）
不要老想去索引。。散列原理才靠普。
凡是巨量的数据，都必须散列...
不要指望银河计算多么多么给力,给力也是分布式运算。。还是散列原理..
优良的代码不如优良的架构.