你这个的前提是
水果个数基本固定
不超过10个，人的个数是不定的，无穷多个
1、不合理
效率很低，用了字符串匹配和全表扫描
都是耗时的操作
2、形成了两个百万级的大表，关联查询效率会很低
我建议三种方案，你自己试验一下哪种效率最高，因为设计和语句本身没有效率高低只说，和使用方式和数据量级别有很大的关系，几万和百万优化的策略是完全不同的
建议1：在你的第2种方案的基础上改进一下，建一个水果字典表C，给每个水果定义一个类似人员的ID号，然后表B存储变成存两个ID关联，并且这两个字段都是索引，表A的人员ID要是主键并且是唯一索引，然后语句如下：
select
*
from
表A
t
where
exists
(select
*
from
表B
where
水果ID
in
(1,3,4)
and
人员ID
=
t.人员ID)
建议2：用空间换效率，union在百万级的效率应该比or要高，所以作为第二种建议，类似于表A的表结构，每类水果都建一个表，然后喜欢这个水果的人就存入这个表，例如表-苹果，表-西瓜，里面存的是喜欢这类水果的人员ID和名称，这种方式是避免了查询，语句如下：
select
*
from
表-苹果
union
select
*
from
表-西瓜
union
select
*
from
表-香蕉
……
建议3：也是用空间换效率，不过用到了or，我估计在百万级效率会最低，在表A（不要存水果的字符串字段了）的基础上扩展10个字段，integer类型，分别对应10种水果，每个字段存0和1两个值，这10个字段都建上索引，语句如下：
select
*
from
表A
where
苹果=1
or
香蕉=1
or
……
② php+mysql优化，百万至千万级快速分页mysql性能到底能有多高
php+Mysql 优化，百万至千万级快速分页
MySql 性能到底能有多高？用了php半年多，真正如此深入的去思考这个问题还是从前天开始。有过痛苦有过绝望，到现在充满信心！MySql 这个数据库绝对是适合dba级的高手去玩的，一般做一点1万篇新闻的小型系统怎么写都可以，用xx框架可以实现快速开发。可是数据量到了10万，百万至千万，他的性能还能那么高吗？一点小小的失误，可能造成整个系统的改写，甚至更本系统无法正常运行！好了，不那么多废话了。用事实说话，看例子：
数据表 collect ( id, title ,info ,vtype) 就这4个字段，其中 title 用定长，info 用text, id 是逐渐，vtype是tinyint，vtype是索引。这是一个基本的新闻系统的简单模型。现在往里面填充数据，填充10万篇新闻。
最后collect 为 10万条记录，数据库表占用硬盘1.6G。OK ,看下面这条sql语句：
select id,title from collect limit 1000,10; 很快；基本上0.01秒就OK，再看下面的
select id,title from collect limit 90000,10; 从9万条开始分页，结果？
8-9秒完成，my god 哪出问题了？？？？其实要优化这条数据，网上找得到答案。看下面一条语句:
select id from collect order by id limit 90000,10; 很快，0.04秒就OK。为什么？因为用了id主键做索引当然快。网上的改法是：
select id,title from collect where id>=(select id from collect order by id limit 90000,1) limit 10;
这就是用了id做索引的结果。可是问题复杂那么一点点，就完了。看下面的语句
select id from collect where vtype=1 order by id limit 90000,10; 很慢，用了8-9秒！
到了这里我相信很多人会和我一样，有崩溃感觉！vtype 做了索引了啊？怎么会慢呢？vtype做了索引是不错，你直接 select id from collect where vtype=1 limit 1000,10; 是很快的，基本上0.05秒，可是提高90倍，从9万开始，那就是0.05*90=4.5秒的速度了。和测试结果8-9秒到了一个数量级。从这里开始有人提出了分表的思路，这个和discuz 论坛是一样的思路。思路如下：
建一个索引表： t (id,title,vtype) 并设置成定长，然后做分页，分页出结果再到 collect 里面去找info 。 是否可行呢？实验下就知道了。
10万条记录到 t(id,title,vtype) 里，数据表大小20M左右。用
select id from t where vtype=1 order by id limit 90000,10; 很快了。基本上0.1-0.2秒可以跑完。为什么会这样呢？我猜想是因为collect 数据太多，所以分页要跑很长的路。limit 完全和数据表的大小有关的。其实这样做还是全表扫描，只是因为数据量小，只有10万才快。OK，来个疯狂的实验，加到100万条，测试性能。
加了10倍的数据，马上t表就到了200多M，而且是定长。还是刚才的查询语句，时间是0.1-0.2秒完成！分表性能没问题？错！因为我们的limit还是9万，所以快。给个大的，90万开始
select id from t where vtype=1 order by id limit 900000,10; 看看结果，时间是1-2秒！
why 分表了时间还是这么长，非常之郁闷！有人说定长会提高limit的性能，开始我也以为，因为一条记录的长度是固定的，mysql 应该可以算出90万的位置才对啊？ 可是我们高估了mysql 的智能，他不是商务数据库，事实证明定长和非定长对limit影响不大？怪不得有人说 discuz到了100万条记录就会很慢，我相信这是真的，这个和数据库设计有关！
难道MySQL 无法突破100万的限制吗？？？到了100万的分页就真的到了极限？？？
答案是： NO !!!! 为什么突破不了100万是因为不会设计mysql造成的。下面介绍非分表法，来个疯狂的测试！一张表搞定100万记录，并且10G 数据库，如何快速分页！
好了，我们的测试又回到 collect表，开始测试结论是： 30万数据，用分表法可行，超过30万他的速度会慢道你无法忍受！当然如果用分表+我这种方法，那是绝对完美的。但是用了我这种方法后，不用分表也可以完美解决！
答案就是：复合索引！有一次设计mysql索引的时候，无意中发现索引名字可以任取，可以选择几个字段进来，这有什么用呢？开始的select id from collect order by id limit 90000,10; 这么快就是因为走了索引，可是如果加了where 就不走索引了。抱着试试看的想法加了 search(vtype,id) 这样的索引。然后测试
select id from collect where vtype=1 limit 90000,10; 非常快！0.04秒完成！
再测试: select id ,title from collect where vtype=1 limit 90000,10; 非常遗憾，8-9秒，没走search索引！
再测试：search(id,vtype)，还是select id 这个语句，也非常遗憾，0.5秒。
综上：如果对于有where 条件，又想走索引用limit的，必须设计一个索引，将where 放第一位，limit用到的主键放第2位，而且只能select 主键！
完美解决了分页问题了。可以快速返回id就有希望优化limit ， 按这样的逻辑，百万级的limit 应该在0.0x秒就可以分完。看来mysql 语句的优化和索引时非常重要的！
好了，回到原题，如何将上面的研究成功快速应用于开发呢？如果用复合查询，我的轻量级框架就没的用了。分页字符串还得自己写，那多麻烦？这里再看一个例子，思路就出来了：
select * from collect where id in (9000,12,50,7000); 竟然 0秒就可以查完！
mygod ，mysql 的索引竟然对于in语句同样有效！看来网上说in无法用索引是错误的！
有了这个结论，就可以很简单的应用于轻量级框架了：
代码如下：
$db=dblink();
$db->pagesize=20;
$sql="select id from collect where vtype=$vtype";
$db->execute($sql);
$strpage=$db->strpage(); //将分页字符串保存在临时变量，方便输出
while($rs=$db->fetch_array()){
$strid.=$rs['id'].',';
}
$strid=substr($strid,0,strlen($strid)-1); //构造出id字符串
$db->pagesize=0; //很关键，在不注销类的情况下，将分页清空，这样只需要用一次数据库连接，不需要再开；
$db->execute("select id,title,url,sTime,gTime,vtype,tag from collect where id in ($strid)");
< php while($rs=$db->fetch_array()): >
<tr>
<td$amp;>amp;$amp;nbsp;< php echo $rs['id']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['url']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['sTime']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['gTime']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['vtype']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;<a act=show&id=< php echo $rs['id']; $amp;>quot;$ target="_blank"$amp;>amp;$lt; php echo $rs['title']; $amp;>amp;$lt;/a$amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['tag']; $amp;>amp;$lt;/td>
</tr>
< php endwhile; >
</table>
< php
echo $strpage;
通过简单的变换，其实思路很简单：1）通过优化索引，找出id，并拼成 "123,90000,12000" 这样的字符串。2）第2次查询找出结果。
小小的索引+一点点的改动就使mysql 可以支持百万甚至千万级的高效分页！
通过这里的例子，我反思了一点：对于大型系统，PHP千万不能用框架，尤其是那种连sql语句都看不到的框架！因为开始对于我的轻量级框架都差点崩溃！只适合小型应用的快速开发，对于ERP,OA，大型网站，数据层包括逻辑层的东西都不能用框架。如果程序员失去了对sql语句的把控，那项目的风险将会成几何级数增加！尤其是用mysql 的时候，mysql 一定需要专业的dba 才可以发挥他的最佳性能。一个索引所造成的性能差别可能是上千倍！
PS: 经过实际测试，到了100万的数据，160万数据，15G表，190M索引，就算走索引，limit都得0.49秒。所以分页最好别让别人看到10万条以后的数据，要不然会很慢！就算用索引。经过这样的优化，mysql到了百万级分页是个极限！但有这样的成绩已经很不错，如果你是用sqlserver肯定卡死！而 160万的数据用 id in (str) 很快，基本还是0秒。如果这样，千万级的数据，mysql应该也很容易应付。
③ sql 多表链接，数据量都百万级别，如何效率优化
用好索引
用更好的查找引擎（/数据库）
做好表设计
实在不行，就用队列查询
④ 面试软件运维SQL数据库一般问什么
Mirror+Replication 自动切换
在线CPU调整
备份与还原
核心数据多层保障
架构设计扩充系统读能力
SSB + Replication
在线扩充数据库读能力
群集在线添加节点
其实说白了就是安全与性能
⑤ 搭建一个日点击量百万以上的 电子商务网站，它的硬件设备投资大概会是多少
百万级访问量网站的技术准备工作
当今从纯网站技术上来说，因为开源模式的发展，现在建一个小网站已经很简单也很便宜，所以很多人都把创业方向定位在互联网应用。这些人里大多数不是很懂技术，或者不是那么精通，而网站开发维护方面的知识又很分散，学习成本太高，所以这篇文章将这些知识点结合起来，系统的来说，一个从日几千访问的小小网站，到日访问一两百万的小网站，中间可能会产生什么问题，以及怎么才能在一开始做足工作尽量避免这些问题。
你的网站因为努力经营，访问量逐渐升高，在升高的过程中，问题也可能开始显现了。因为带宽的增加、硬件的扩展、人员的扩张所带来的成本提高是显而易见的，而还有相当大的一部分成本是因为代码重构、架构重构，甚至底层开发语言更换引起的，最坏的情况就是数据丢失，所有努力付之一炬。这类成本支出大多数在一开始就可以避免，先打好基础，往后可以省很多精力，少操很多心。
对于不同的初期投资成本，技术路线的选择是不同的。这里假设网站刚刚只是一个构想，计划第一年服务器硬件带宽投入5万左右。对于这个资金额度，有很多种方案可选择，例如租用虚拟主机、租用单独服务器，或者流行的私有云，或者托管服务器。前两种选择，网站发展到一定规模时需迁移，那时再重做规划显然影响更大。服务器托管因为配置自主、能完全掌握控制权，所以有一定规模的网站基本都是这种模式。采用自己托管服务器的网站，一开始要注意以下几点——
一、开发语言
一般来说，技术人员（程序员）都是根据自己技术背景选择自己最熟悉的语言，不过不可能永远是一个人写程序，所以在语言的选择上还要是要费些心思。首先明确一点，无论用什么语言，最终代码质量是看管理，因此我们从前期开发成本分析。现在国内流行的适用于网站的语言，大概有java、php、.net、 python、ruby这五大阵营。python和ruby因为在国内流行的比较晚，现在人员还是相对难招一些。.net平台的人相对多，但是到后期需要解决性能问题时，对人员技能的要求比较高。剩余的java、php用人可以说是最多的。java和php无法从语言层面做比较，但对于初期，应用几乎都是靠前端支撑的网站来说，php入门简单、编写快速，优势相对大一点。至于后端例如行为分析、银行接口、异步消息处理等，等真正需要时，就要根据不同业务需求来选择不同语言了。
二、代码版本管理
稍微有点规模的网站就需要使用代码版本管理了。代码版本管理两点最大的好处，一是方便协同工作，二是有历史记录可查询比较。代码版本管理软件有很多，vss/cvs/svn/hg等，目前国内都比较流行，其中svn的普及度还是很高的。
假设选了svn，那么有几点考虑。一是采用什么树结构。初期可能只有一条主干，往后就需要建立分支，例如一条开发分支，一条上线分支，再往后，可能要每个小组一个分支。建议一开始人少时选择两条分支，开发和线上，每个功能本地测试无误后提交到开发分支，最后统一测试，可以上线时合并到上线分支。如果每人都建自己的分支，合并时会浪费很大精力，对于几乎每天都要修改几次的WEB应用来说，所费时间太多。
向服务器部署代码，可以手工部署也可以自动部署。手工部署相对简单，一般可直接在服务器上svn update，或者找个新目录svn checkout，再把web root给ln -s过去。应用越复杂，部署越复杂，没有什么统一标准，只是别再用ftp上传那种形式，一是上传时文件引用不一致错误率增加，二是很容易出现开发人员的版本跟线上版本不一致，导致本来想改个错字结果变成回滚。如果有多台服务器还是建议自动部署，更换代码的机器从当前服务池中临时撤出，更新完毕后再重新加入。
三、服务器硬件
在各个机房里，靠一台服务器孤独支撑的网站数不清，但如果资金稍微充足，建议至少三台的标准配置，分别用作web处理、数据库、备份。web服务器至少要8G内存，双sata raid1，如果经济稍微宽松，或静态文件或图片多，则15k sas raid10。数据库至少16G内存，15k sas raid 10。备份服务器最好跟数据库服务器同等配置。硬件可以上整套品牌，也可以兼容机，也可以半品牌半组装，取决于经济能力。当然，这是典型的搭配，有些类型应用的性能瓶颈首先出现在web上，那种情况就要单独分析了。
web服务器可以既跑程序又当内存缓存，数据库服务器则只跑主数据库（假如是MySQL的话），备份服务器所承担就相对多一些，web配置、缓存配置、数据库配置都要跟前两台一致，这样WEB和数据库任意一台出问题，很容易就可以将备份服务器切换过去临时顶替，直到解决完问题。要注意，硬件是随时可能坏掉的，特别是硬盘，所以宁可WEB服务器跟数据库服务器放在一起，也一定不能省掉备份，备份一定要异机，并且有异步，电力故障、误操作都可能导致一台机器上的所有数据丢失。很多的开源备份方案可选择，最简单的就是rsync，写crontab里，定时同步。备份和切换，建议多做测试，选最安全最适合业务的，并且尽可能异地备份。
四、机房
三种机房尽量不要选：联通访问特别慢的电信机房、电信访问特别慢的联通机房、电信联通访问特别慢的移动或铁通机房。机房要尽可能多的实地参观，多测试，找个网络质量好，管理严格的机房。机房可以说是非常重要，直接关系到网站访问速度，网站访问速度直接关系到用户体验，访问速度很慢的网站，很难获得用户青睐。
五、架构
在大方向上，被熟知的架构是web负载均衡+数据库主从+缓存+分布式存储+队列。在一开始，按照可扩展的原则设计和编程就可以。只是要多考虑缓存失效时的雪崩效应、主从同步的数据一致性和时间差、队列的稳定性和失败后的重试策略、文件存储的效率和备份方式等等意外情况。缓存失效、数据库复制中断、队列写入错误、电源损坏，在实际运维中经常发生，如果不注意这些，出现问题时恢复期可能会超出预期很长时间。
六、服务器软件
操作系统Linux很流行。在没有专业运维人员的情况下，应倾向于择使用的人多、社区活跃、配置方便、升级方便的发行版，例如RH系列、 debian、ubuntu server等，硬件和操作系统要一起选择，看是否有适合的驱动，如果确定用某种商业软件或解决方案，也要提前知晓其对哪种操作系统支持最佳。web服务器方面，apache、nginx、lighttpd三大系列中，apache占有量还是最大，但是想把性能调教好还是需要很专业的，nginx和 lighttpd在不需要太多调整的情况下可以达到一个比较不错的性能。无论选择什么软件，除非改过这些软件或你的程序真的不兼容新版本，否则尽量版本越新越好，版本新，意味着新特性增多、BUG减少、性能增加。一个典型的php网站，基本上大多数人都没改过任何服务器软件源代码，绝大多数情况是能平稳的升级到新版本的。类似于jdk5到 jdk6，python2到python3这类变动比较大的升级还是比较少见的。看看ChangeLog，看看升级说明，结合自己情况评估测试一下，越早升级越好，升级的越晚，所花费的成本越高。对于软件包，尽量使用发行版内置的包管理工具，没有特殊要求时不建议自己编译，那样对将来运维不利。
七、数据库
几乎所有操作最后都要落到数据库身上，它又最难扩展（存储也挺难）。数据库常见的扩展方法有复制、分片，设计时要考虑到每种应用的数据如何复制、分片，当然这种考虑一般会推迟到技术设计时期。在初期进行数据库结构设计时，要根据不同的业务类型和增长量预期来考虑是否要分库、分区，并且尽量不要使用联合查询、不使用自增ID以方便分片。复制延时问题、主从数据库数据一致性问题，可以自己写或者用已有的运维工具进行检测。
用存储过程是比较难扩展的，这种情形多发生于传统C/S，特别是OA系统转换过来的开发人员。低成本网站不是一两台小型机跑一个数据库处理所有业务的模式，是机海作战。方便水平扩展比那点预分析时间和网络传输流量要重要的多的多。
另外，现在流行一种概念叫NoSQL，可以理解为非传统关系型数据库。实际应用中，网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等，这都不是传统关系数据库所擅长的，于是就产生了很多非关系型数据库，比如Redis/TC&TT/MongoDB/Memcachedb等，在测试中，这些几乎都达到了每秒至少一万次的写操作，内存型的甚至5万以上。在设计时，可根据业务特点和性能要求来选择是否使用这类数据库。例如 MongoDB，几句配置就可以组建一个复制+自动分片+failover的环境，文档化的存储也简化了传统设计库结构再开发的模式。但是当你决定采用一项技术时，一定要真正了解其优劣，例如可能你所选择的技术并不能支持你所需要的事务和数据一致性要求。
八、文件存储
存储的分布几乎跟数据库扩展一样困难，不过只有百万的PV的情况下，磁盘IO方面一般不会成大问题，一两台采用SATA做条带RAID的机器可以应付，反而是自己做异步备份比较复杂，因为小文件多。如果只有一台机器做存储，可以做简单的优化，例如放最小缩略图的分区和放中等缩略图的分区，根据平均大小调整一下块大小。存储要规划好目录结构，否则文件增多后维护起来复杂，也不利于扩展。同时还要考虑将来扩容，例如采用LVM，或者把文件根据不同规则散列到不同机器。磁盘IO繁重的情况下更容易出现故障，所以要做好备份，若发现有盘坏掉，要马上行动更换，很多人的硬盘都是坏了一块之后，接二连三的坏下去。
为了将来图片走cdn做准备，一开始最好就将图片的域名分开，且不用主域名。因为很多网站都将cookie设置到了.domain.ltd，如果图片也在这个域名下，很可能因为cookie而造成缓存失效，并且占多余流量，还可能因为浏览器并发线程限制造成访问缓慢。
九、程序
一定硬件条件下，应用能承载多少访问量，很大一部分也取决于程序如何写。程序写的不好，可能一万的访问都承载不了，写的好，可能一两台机器就能承担几百万PV。越是复杂、数据实时性要求越高的应用，优化起来越难，但对普通网站有一个统一的思路，就是尽量向前端优化、减少数据库操作、减少磁盘IO。向前端优化指的是，在不影响功能和体验的情况下，能在浏览器执行的不要在服务端执行，能在缓存服务器上直接返回的不要到应用服务器，程序能直接取得的结果不要到外部取得，本机内能取得的数据不要到远程取，内存能取到的不要到磁盘取，缓存中有的不要去数据库查询。减少数据库操作指减少更新次数、缓存结果减少查询次数、将数据库执行的操作尽可能的让你的程序完成（例如join查询），减少磁盘IO指尽量不使用文件系统作为缓存、减少读写文件次数等。程序优化永远要优化慢的部分，换语法是无法“优化”的。
然而编程时不应该把重点放在优化上，应该关注扩展性。当今的WEB应用，需求变化非常之快，适应多种需求的架构是不存在的，我们的扩展性就要把要点放在跟底层交互的架构上，例如持久化数据的存取规则、缓存的存取规则等，还有一些共用服务，例如用户信息等。先把不变的部分做完善，剩下的部分就很容易将精力放在业务逻辑上面了。
⑥ sql server百万级的数据，如何提高查询效率
百万级的数据对sqlserver来说并不算大，只要数据库结构设计合理、sql指令合理，效率不会太差。
1.充分利用索引
2.尽量减少运算
3.尽量减小执行初期的数据量
4.减小循环
......