一个在线词典系统，假设每个用户查询过的单词在1万以内，如果有1万-10万用户
考虑如果做一个user-word关联表，理论上条目会有1-10亿条以上，似乎查询效率不高。
因为各用户之间没有什么关联，如果为每个用户建立一个表，放弃使用不多的user-word表及其查询统计功能，但是性能是不是提高很多，这样设计如何？
建立1-10万个表可行吗？如果这个方法不好，还有其他办法吗？
词库一个表
table word:
word char(50) primary key
pronounce char(50)
meaning text
每个用户一个表，
用户1
table user00001:
user_id int primary key auto_increment
login_name char(20)
passwd char(50)
word char(50) //查询过的单词，假设10000条以内
count int //查询次数
...
...
...
用户9999
table user09999:
user_id int primary key auto_increment
login_name char(20)
passwd char(50)
word char(50) //查询过的单词，假设10000条以内
count int //查询次数
10 个解决方案
#1
查询效率高不高关键在于是否使用索引。
1亿条记录，并不多。况且你有必要把用户查询过的所有词都记录下来么？只记个10来条不就可以了。
1亿条记录，并不多。况且你有必要把用户查询过的所有词都记录下来么？只记个10来条不就可以了。
#2
有几个用户会去查1万个词啊
#3
为什么要记录每个用户查询了哪些单词呢？
#4
查询速度慢只是楼主想象而已，索引的效率是很高的。
你要说说记录这些数据的用途，或许还可以帮你设计一下。
要是你的数据是统计分析用的，查询慢就慢咯，反正统计就是要时间的。
要是你是给用户一个功能，让他可以看到他以前查的的词的话，这个功能不是所有用户都会用的，你可以搞个vip什么的，要用户经过一定程序才有此功能，那么那些不需要这个功能的用户自然通常都不会去用，你就大大减少了记录数了。而且索引查询速度是很快的，你最好用int，bigint这种做索引，几亿记录也不会慢的。而且我觉得你估计的数太大了，谁会查这么多词。
考6级的把6级词都查一遍才6000多。而且你还可以限制每个人的记录的词数的。你觉得我给你10000个你查过的词你会去看吗？
你要说说记录这些数据的用途，或许还可以帮你设计一下。
要是你的数据是统计分析用的，查询慢就慢咯，反正统计就是要时间的。
要是你是给用户一个功能，让他可以看到他以前查的的词的话，这个功能不是所有用户都会用的，你可以搞个vip什么的，要用户经过一定程序才有此功能，那么那些不需要这个功能的用户自然通常都不会去用，你就大大减少了记录数了。而且索引查询速度是很快的，你最好用int，bigint这种做索引，几亿记录也不会慢的。而且我觉得你估计的数太大了，谁会查这么多词。
考6级的把6级词都查一遍才6000多。而且你还可以限制每个人的记录的词数的。你觉得我给你10000个你查过的词你会去看吗？
#5
感谢各位的帮助，大概情况是这样：
整个系统的统计次数不多
查10000个单词是个上限，估计靠GRE的人也够用了，大部分人可能用到50%以下。5千还是1万这个无所谓，基本还是同一个数量级的问题。更多的是每个人的统计，比如我查过了2000个词，不同的词查过的次数也不同，统计的重点在于用户本身的行为分析。举个例子：比如按照我查词的次数进行排序，下次我再查词的时候，旁边可以循环滚动那些以前查过的词，复习一下。
如果是论坛或者blog之类的系统，每个用户的统计次数都不多，数据库随便怎么设计都问题不大。但是这个系统每个用户每次使用的时候都要统计一次，如果几千人在线，每秒钟成百上千的统计分析，实在担心负载和性能，所以格外强调设计。
如果为了提高性能每次都创建临时表，那我还不如一开始就分开算了，所以才有这个“十万用户十万表”的问题
整个系统的统计次数不多
查10000个单词是个上限，估计靠GRE的人也够用了，大部分人可能用到50%以下。5千还是1万这个无所谓，基本还是同一个数量级的问题。更多的是每个人的统计，比如我查过了2000个词，不同的词查过的次数也不同，统计的重点在于用户本身的行为分析。举个例子：比如按照我查词的次数进行排序，下次我再查词的时候，旁边可以循环滚动那些以前查过的词，复习一下。
如果是论坛或者blog之类的系统，每个用户的统计次数都不多，数据库随便怎么设计都问题不大。但是这个系统每个用户每次使用的时候都要统计一次，如果几千人在线，每秒钟成百上千的统计分析，实在担心负载和性能，所以格外强调设计。
如果为了提高性能每次都创建临时表，那我还不如一开始就分开算了，所以才有这个“十万用户十万表”的问题
#6
我再说一个吧，你的这个设计，是不应该把这些信息全部放在服务端的，就算程序再好，硬件带宽也跟不上的，特别是带宽，全部信息都有服务端发出，你用多少的带宽啊。
按你这个说法，个人的统计应该放在每个客户端，有客户端的都是用自己的表统计的，这样才是可行的。
远程的服务器应该只提供词汇。
按你这个说法，个人的统计应该放在每个客户端，有客户端的都是用自己的表统计的，这样才是可行的。
远程的服务器应该只提供词汇。
#7
楼主: 按你的需求描述，你这样的设计似乎也没有问题。但可能存在一个后期问题。如果用户表需要调整，那么...?
#8
是啊，这是一个问题，后期调整结构只有靠程序批量来调整了。
如果以用户为主键索引能够达到跟独立用户表近似的性能，当然用一个表比较好。
大部分查询是基于某个user_id下的统计
select *
from user-words
where user_id = N
and count>5
请有经验的朋友透露一下大概同等复杂度的亿条记录查询的速度，查询一次大概多少时间
如果以用户为主键索引能够达到跟独立用户表近似的性能，当然用一个表比较好。
table user-words:
user_id int primary key
word char(50) //查询过的单词，假设10000条以内
count int //查询次数
...
大部分查询是基于某个user_id下的统计
select *
from user-words
where user_id = N
and count>5
请有经验的朋友透露一下大概同等复杂度的亿条记录查询的速度，查询一次大概多少时间
#9
晕。有这样设计的吗？
1W张表？
1W张表？
#10
一个用户表，专门建立用户信息
一个用户查询表，关联用户ID并且包含用户的查询需求。
一个用户查询表，关联用户ID并且包含用户的查询需求。
#1
查询效率高不高关键在于是否使用索引。
1亿条记录，并不多。况且你有必要把用户查询过的所有词都记录下来么？只记个10来条不就可以了。
1亿条记录，并不多。况且你有必要把用户查询过的所有词都记录下来么？只记个10来条不就可以了。
#2
有几个用户会去查1万个词啊
#3
为什么要记录每个用户查询了哪些单词呢？
#4
查询速度慢只是楼主想象而已，索引的效率是很高的。
你要说说记录这些数据的用途，或许还可以帮你设计一下。
要是你的数据是统计分析用的，查询慢就慢咯，反正统计就是要时间的。
要是你是给用户一个功能，让他可以看到他以前查的的词的话，这个功能不是所有用户都会用的，你可以搞个vip什么的，要用户经过一定程序才有此功能，那么那些不需要这个功能的用户自然通常都不会去用，你就大大减少了记录数了。而且索引查询速度是很快的，你最好用int，bigint这种做索引，几亿记录也不会慢的。而且我觉得你估计的数太大了，谁会查这么多词。
考6级的把6级词都查一遍才6000多。而且你还可以限制每个人的记录的词数的。你觉得我给你10000个你查过的词你会去看吗？
你要说说记录这些数据的用途，或许还可以帮你设计一下。
要是你的数据是统计分析用的，查询慢就慢咯，反正统计就是要时间的。
要是你是给用户一个功能，让他可以看到他以前查的的词的话，这个功能不是所有用户都会用的，你可以搞个vip什么的，要用户经过一定程序才有此功能，那么那些不需要这个功能的用户自然通常都不会去用，你就大大减少了记录数了。而且索引查询速度是很快的，你最好用int，bigint这种做索引，几亿记录也不会慢的。而且我觉得你估计的数太大了，谁会查这么多词。
考6级的把6级词都查一遍才6000多。而且你还可以限制每个人的记录的词数的。你觉得我给你10000个你查过的词你会去看吗？
#5
感谢各位的帮助，大概情况是这样：
整个系统的统计次数不多
查10000个单词是个上限，估计靠GRE的人也够用了，大部分人可能用到50%以下。5千还是1万这个无所谓，基本还是同一个数量级的问题。更多的是每个人的统计，比如我查过了2000个词，不同的词查过的次数也不同，统计的重点在于用户本身的行为分析。举个例子：比如按照我查词的次数进行排序，下次我再查词的时候，旁边可以循环滚动那些以前查过的词，复习一下。
如果是论坛或者blog之类的系统，每个用户的统计次数都不多，数据库随便怎么设计都问题不大。但是这个系统每个用户每次使用的时候都要统计一次，如果几千人在线，每秒钟成百上千的统计分析，实在担心负载和性能，所以格外强调设计。
如果为了提高性能每次都创建临时表，那我还不如一开始就分开算了，所以才有这个“十万用户十万表”的问题
整个系统的统计次数不多
查10000个单词是个上限，估计靠GRE的人也够用了，大部分人可能用到50%以下。5千还是1万这个无所谓，基本还是同一个数量级的问题。更多的是每个人的统计，比如我查过了2000个词，不同的词查过的次数也不同，统计的重点在于用户本身的行为分析。举个例子：比如按照我查词的次数进行排序，下次我再查词的时候，旁边可以循环滚动那些以前查过的词，复习一下。
如果是论坛或者blog之类的系统，每个用户的统计次数都不多，数据库随便怎么设计都问题不大。但是这个系统每个用户每次使用的时候都要统计一次，如果几千人在线，每秒钟成百上千的统计分析，实在担心负载和性能，所以格外强调设计。
如果为了提高性能每次都创建临时表，那我还不如一开始就分开算了，所以才有这个“十万用户十万表”的问题
#6
我再说一个吧，你的这个设计，是不应该把这些信息全部放在服务端的，就算程序再好，硬件带宽也跟不上的，特别是带宽，全部信息都有服务端发出，你用多少的带宽啊。
按你这个说法，个人的统计应该放在每个客户端，有客户端的都是用自己的表统计的，这样才是可行的。
远程的服务器应该只提供词汇。
按你这个说法，个人的统计应该放在每个客户端，有客户端的都是用自己的表统计的，这样才是可行的。
远程的服务器应该只提供词汇。
#7
楼主: 按你的需求描述，你这样的设计似乎也没有问题。但可能存在一个后期问题。如果用户表需要调整，那么...?
#8
是啊，这是一个问题，后期调整结构只有靠程序批量来调整了。
如果以用户为主键索引能够达到跟独立用户表近似的性能，当然用一个表比较好。
大部分查询是基于某个user_id下的统计
select *
from user-words
where user_id = N
and count>5
请有经验的朋友透露一下大概同等复杂度的亿条记录查询的速度，查询一次大概多少时间
如果以用户为主键索引能够达到跟独立用户表近似的性能，当然用一个表比较好。
table user-words:
user_id int primary key
word char(50) //查询过的单词，假设10000条以内
count int //查询次数
...
大部分查询是基于某个user_id下的统计
select *
from user-words
where user_id = N
and count>5
请有经验的朋友透露一下大概同等复杂度的亿条记录查询的速度，查询一次大概多少时间
#9
晕。有这样设计的吗？
1W张表？
1W张表？
#10
一个用户表，专门建立用户信息
一个用户查询表，关联用户ID并且包含用户的查询需求。
一个用户查询表，关联用户ID并且包含用户的查询需求。