A*******n
发帖数: 625 | 1 一个简单的问题， 一个table，里面有个column （customername）。 数据可能有几百
w条记录。
select *
from table
where customername like '%xxx%'
可能会慢的要死， 有什么其他办法吗 |
s**********o
发帖数: 14359 | 2 你的TABLE本身就没做好吧，为什么不是FIRSNAME ,LASTNAME各一个COLUMN呢
你LIKE未必能找到正确的人名，比如LIKE '%JOHN%'，叫JOHN的多了
还可能是JON或者JONNATHAN，所以有可能就找不到；WILLIAM叫BILL的，
ROBERT叫BOB的都是很常见的，一般LASTNAME更可靠一些，直接=LASTNAME
MATCH的更准确 |
c*****d
发帖数: 6045 | 3 即便在customername字段上有索引
like '%xxx%'也不会使用该索引 |
B*****g
发帖数: 34098 | 4 google "full text search"
【在 A*******n 的大作中提到】
: 一个简单的问题， 一个table，里面有个column （customername）。 数据可能有几百
: w条记录。
: select *
: from table
: where customername like '%xxx%'
: 可能会慢的要死， 有什么其他办法吗
|
A*******n
发帖数: 625 | 5 no permission
【在 B*****g 的大作中提到】
: google "full text search"
|
A*******n
发帖数: 625 | 6 同意，没办法改也不想改，很多是公司的名字。
【在 s**********o 的大作中提到】
: 你的TABLE本身就没做好吧，为什么不是FIRSNAME ,LASTNAME各一个COLUMN呢
: 你LIKE未必能找到正确的人名，比如LIKE '%JOHN%'，叫JOHN的多了
: 还可能是JON或者JONNATHAN，所以有可能就找不到；WILLIAM叫BILL的，
: ROBERT叫BOB的都是很常见的，一般LASTNAME更可靠一些，直接=LASTNAME
: MATCH的更准确
|
A*******n
发帖数: 625 | 7 那就是无解的意思了， 酷毙大师
【在 c*****d 的大作中提到】
: 即便在customername字段上有索引
: like '%xxx%'也不会使用该索引
|
s**********o
发帖数: 14359 | 8 在自己机器上装个DATABASE，用SSIS搞个SPLIT FUNCTION把数据重新倒一遍
FIRST, MIDDLE, LAST，TITLE，这样是比较干净的做法，公司的DATA MODEL
没做好，只能自己想办法
【在 A*******n 的大作中提到】
: 那就是无解的意思了， 酷毙大师
|
w****w
发帖数: 521 | 9 解还是有的，就看你肯花多大本钱。如果xxx经常重复搜索，可以建一个index table。
也可以按列中的词做索引。最终的办法是搬到hadoop或greenplum那样的MPP系统去。
【在 A*******n 的大作中提到】
: 那就是无解的意思了， 酷毙大师
|
w****w
发帖数: 521 | 10 解还是有的，就看你肯花多大本钱。如果xxx经常重复搜索，可以建一个index table。
也可以按列中的词做索引。最终的办法是搬到hadoop或greenplum那样的MPP系统去。
【在 A*******n 的大作中提到】
: 那就是无解的意思了， 酷毙大师
|
|
|
A*******n
发帖数: 625 | 11 一个简单的问题， 一个table，里面有个column （customername）。 数据可能有几百
w条记录。
select *
from table
where customername like '%xxx%'
可能会慢的要死， 有什么其他办法吗 |
s**********o
发帖数: 14359 | 12 你的TABLE本身就没做好吧，为什么不是FIRSNAME ,LASTNAME各一个COLUMN呢
你LIKE未必能找到正确的人名，比如LIKE '%JOHN%'，叫JOHN的多了
还可能是JON或者JONNATHAN，所以有可能就找不到；WILLIAM叫BILL的，
ROBERT叫BOB的都是很常见的，一般LASTNAME更可靠一些，直接=LASTNAME
MATCH的更准确 |
c*****d
发帖数: 6045 | 13 即便在customername字段上有索引
like '%xxx%'也不会使用该索引 |
B*****g
发帖数: 34098 | 14 google "full text search"
【在 A*******n 的大作中提到】
: 一个简单的问题， 一个table，里面有个column （customername）。 数据可能有几百
: w条记录。
: select *
: from table
: where customername like '%xxx%'
: 可能会慢的要死， 有什么其他办法吗
|
A*******n
发帖数: 625 | 15 no permission
【在 B*****g 的大作中提到】
: google "full text search"
|
A*******n
发帖数: 625 | 16 同意，没办法改也不想改，很多是公司的名字。
【在 s**********o 的大作中提到】
: 你的TABLE本身就没做好吧，为什么不是FIRSNAME ,LASTNAME各一个COLUMN呢
: 你LIKE未必能找到正确的人名，比如LIKE '%JOHN%'，叫JOHN的多了
: 还可能是JON或者JONNATHAN，所以有可能就找不到；WILLIAM叫BILL的，
: ROBERT叫BOB的都是很常见的，一般LASTNAME更可靠一些，直接=LASTNAME
: MATCH的更准确
|
A*******n
发帖数: 625 | 17 那就是无解的意思了， 酷毙大师
【在 c*****d 的大作中提到】
: 即便在customername字段上有索引
: like '%xxx%'也不会使用该索引
|
s**********o
发帖数: 14359 | 18 在自己机器上装个DATABASE，用SSIS搞个SPLIT FUNCTION把数据重新倒一遍
FIRST, MIDDLE, LAST，TITLE，这样是比较干净的做法，公司的DATA MODEL
没做好，只能自己想办法
【在 A*******n 的大作中提到】
: 那就是无解的意思了， 酷毙大师
|
w****w
发帖数: 521 | 19 解还是有的，就看你肯花多大本钱。如果xxx经常重复搜索，可以建一个index table。
也可以按列中的词做索引。最终的办法是搬到hadoop或greenplum那样的MPP系统去。
【在 A*******n 的大作中提到】
: 那就是无解的意思了， 酷毙大师
|
w****w
发帖数: 521 | 20 解还是有的，就看你肯花多大本钱。如果xxx经常重复搜索，可以建一个index table。
也可以按列中的词做索引。最终的办法是搬到hadoop或greenplum那样的MPP系统去。
【在 A*******n 的大作中提到】
: 那就是无解的意思了， 酷毙大师
|
|
|
s**********o
发帖数: 14359 | 21 就MATCH个LASTNAME还要搬系统啊，工程浩大
【在 w****w 的大作中提到】
: 解还是有的，就看你肯花多大本钱。如果xxx经常重复搜索，可以建一个index table。
: 也可以按列中的词做索引。最终的办法是搬到hadoop或greenplum那样的MPP系统去。
|
A*******n
发帖数: 625 | 22 都觉的麻烦，我的老板有个特点最好不要改原来的东西。 这点我觉的很要命，特别是
对我们这样的人。 |
j*******7
发帖数: 6300 | 23 如果这个表里只有两个column: id and customername,再投资把数据存储reorg的很紧
密高效（包括考虑使用RAM盘），估计对现代机器即使table scan也会很快的。 |
n****f
发帖数: 3580 | 24 我也是这么想的，而且在Oracle作了个测试。
我建了一张1千万记录的表，只有两个column, 结果发现，即使没有index, 下列query
运行很快：
select *
from table1
where customername like '%xxx%'
【在 j*******7 的大作中提到】
: 如果这个表里只有两个column: id and customername,再投资把数据存储reorg的很紧
: 密高效（包括考虑使用RAM盘），估计对现代机器即使table scan也会很快的。
|
A*******n
发帖数: 625 | 25 问题是有100个columns
【在 j*******7 的大作中提到】
: 如果这个表里只有两个column: id and customername,再投资把数据存储reorg的很紧
: 密高效（包括考虑使用RAM盘），估计对现代机器即使table scan也会很快的。
|
s**********o
发帖数: 14359 | 26 你不会搞个TEMP TABLE就2个COLUMN,找到后再MATCH回去啊
【在 A*******n 的大作中提到】
: 问题是有100个columns
|
j*******7
发帖数: 6300 | 27 Try creating a nonclustered index on id and customername, and optimize the
query to make sure it will scan and only scan that index.
If want to be faster, partition that index in order to make the index can be
scanned in parallel.
Anyway, I think full-text index is better solution, and the method should
not affect the application side.
【在 A*******n 的大作中提到】
: 问题是有100个columns
|
s**********o
发帖数: 14359 | 28 没看到人不让你在SERVER改东西么，FULLTEXT是个SERVICE，开启是要占很多内存的
be
【在 j*******7 的大作中提到】
: Try creating a nonclustered index on id and customername, and optimize the
: query to make sure it will scan and only scan that index.
: If want to be faster, partition that index in order to make the index can be
: scanned in parallel.
: Anyway, I think full-text index is better solution, and the method should
: not affect the application side.
|
j*******7
发帖数: 6300 | 29 看到了。只是觉得FULLTEXT这个东西应该是个挺成熟的东西了吧，不过本人也没有实战
过。如果只是领导不许就有点好像意味着公司人际关系可能有问题了。Server不可能永
远不能动，只要有必要就应该支持，DBA或Developer应该说服决策者考虑。感觉这个改
动其实并不大，充分测试一下就好了。
【在 s**********o 的大作中提到】
: 没看到人不让你在SERVER改东西么，FULLTEXT是个SERVICE，开启是要占很多内存的
:
: be
|
A*******n
发帖数: 625 | 30 公司结构说起来简单，可是头什么人都不信那就没办法了。以前提的建议可以很容易解
决问题（几天就搞定的东西），可是没人采纳，最后请别人做3个月，最后做不下去了
就把东西丢给其他公司管，然后常常查他们对不对。
真的可以自豪的说：
我们虽然时间耗了钱豪了， 可是我们做不了啊，你们还想怎样。 |
|
|
s**********o
发帖数: 14359 | |
A*******n
发帖数: 625 | 32 有可能都不用20分钟，不过我觉的你老板知道你在20分钟内搞定那就一定是你不对了。
呵呵 |
y****w
发帖数: 3747 | 33 这个查询的频率以及SLA是多少？
只是偶尔扫描单表的话，几百万真不是什么事儿。
【在 A*******n 的大作中提到】
: 一个简单的问题， 一个table，里面有个column （customername）。 数据可能有几百
: w条记录。
: select *
: from table
: where customername like '%xxx%'
: 可能会慢的要死， 有什么其他办法吗
|
A*******n
发帖数: 625 | 34 你说的也没错， 问题是有的时候timeout，有的时候没事。 有的时候server 忙的时候
就不好用。 其实可能还是beijing说的，主要是没permission
【在 y****w 的大作中提到】
: 这个查询的频率以及SLA是多少？
: 只是偶尔扫描单表的话，几百万真不是什么事儿。
|
A*******n
发帖数: 625 | 35 你说的也没错， 问题是有的时候timeout，有的时候没事。 有的时候server 忙的时候
就不好用。 其实可能还是beijing说的，主要是没permission
【在 y****w 的大作中提到】
: 这个查询的频率以及SLA是多少？
: 只是偶尔扫描单表的话，几百万真不是什么事儿。
|
y****w
发帖数: 3747 | 36 远水解不了近渴。 想想为啥timeout，你的访问级别是什么，脏读应该够了。
改善点就是增加冗余，单独成表/大小写改写之类，用修改代价换查询和锁。
【在 A*******n 的大作中提到】
: 你说的也没错， 问题是有的时候timeout，有的时候没事。 有的时候server 忙的时候
: 就不好用。 其实可能还是beijing说的，主要是没permission
|
