昨天的文章 全球化的误区，本地化的机会 ，评论里，有人说，搜索引擎技术似乎不需要本地化，这一看就是彻底不懂这个领域的人讲的。当然，实话说，如果有人说，google在中文本地化方面做得非常好，我是可以部分同意的，同意的比例可能会比google工程师少一些。但我相信google工程师也会告诉你，搜索引擎是需要本地化的。

 

今天写篇科普文，讲讲搜索引擎的技术机理和市场竞争的一些特点。当然，作为从事或有兴趣从事流量运营的朋友，是可以用另一个角度去理解本文。

 

搜索引擎的核心技术架构，大体包括以下三块，第一，是蜘蛛/爬虫技术；第二，是索引技术；第三是查询展现的技术； 当然，我不是搜索引擎的架构师，我只能用比较粗浅的方式来做一个结构的切分。

 

1、 蜘蛛，也叫爬虫，是将互联网的信息，抓取并存储的一种技术实现。

搜索引擎的信息收录，很多不明所以的人会有很多误解，以为是付费收录，或者有什么其他特殊的提交技巧，其实并不是，搜索引擎通过互联网一些公开知名的网站，抓取内容，并分析其中的链接，然后有选择的抓取链接里的内容，然后再分析其中的链接，以此类推，通过有限的入口，基于彼此链接，形成强大的信息抓取能力。

 

有些搜索引擎本身也有链接提交入口，但基本上，不是主要的收录入口，不过作为创业者，建议了解一下相关信息，百度，google都有站长平台和管理后台，这里很多内容是需要非常非常认真的对待的。

 

反过来说，在这样的原理下，一个网站，只有被其他网站所链接，才有机会被搜索引擎抓取。如果这个网站没有外部链接，或者外部链接在搜索引擎中被认为是垃圾或无效链接，那么搜索引擎可能就不抓取他的页面。

 

分析和判断搜索引擎是否抓取了你的页面，或者什么时候抓取你的页面，只能通过服务器上的访问日志来查询，如果是cdn就比较麻烦。 而基于网站嵌入代码的方式，不论是cnzz，百度统计，还是google analytics，都无法获得蜘蛛抓取的信息，因为这些信息不会触发这些代码的执行。

 

一个比较推荐的日志分析软件是awstats。

在十多年前，分析百度蜘蛛抓取轨迹和更新策略，是很多草根站长每日必做的功课，比如现在身价几十亿的知名80后上市公司董事长，当年在某站长论坛就是以此准确的分析判断而封神，很年轻的时候就已经是站长圈的一代偶像。

 

但关于蜘蛛的话题，并不只基于链接抓取这么简单，延伸来说

 

第一，网站拥有者可以选择是否允许蜘蛛抓取，有一个robots.txt的文件是来控制这个的。

 

一个经典案例是 https://www.taobao.com/robots.txt

你会看到，淘宝至今仍有关键目录不对百度蜘蛛开放，但对google开放。

 

另一个经典案例是 http://www.baidu.com/robots.txt

你看出什么了？你可能什么都没看出来，我提醒一句，百度实质上全面禁止了360的蜘蛛抓取。

 

但这个协议只是约定俗成，实际上并没有强制约束力，所以，你们猜猜，360遵守了百度的蜘蛛抓取禁止么？

 

第二，最早抓取是基于网站彼此的链接为入口，但实际上，并不能肯定的说，有可能存在其他抓取入口，比如说，

客户端插件或浏览器， 免费网站统计系统的嵌入式代码。

会不会成为蜘蛛抓取的入口，我只能说，有这个可能。

 

所以我跟很多创业者说，中国做网站，放百度统计，海外做网站，放google analytics，是否会增加搜索引擎对你网站的收录？我只能说猜测，有这个可能。

 

第三，无法被抓取的信息

 

有些网站的内容链接，用一些javascript特殊效果完成，比如浮动的菜单等等，这种连接，有可能搜索引擎的蜘蛛程序不识别，当然，我只是说有可能，现在搜索引擎比以前聪明，十多年前很多特效链接是不识别的，现在会好一些。

 

需要登录，需要注册才能访问的页面，蜘蛛是无法进入的，也就是无法收录。

 

有些网站会给搜索特殊页面，就是蜘蛛来能看到内容（蜘蛛访问会有特殊的客户端标记，服务端识别和处理并不复杂），人来了要登录才能看，但这样做其实是违反了收录协议（需要人和蜘蛛看到的同样的内容，这是绝大部分搜索引擎的收录协议），有可能遭到搜索引擎处罚。

 

所以一个社区要想通过搜索引擎带来免费用户，必须让访客能看到内容，哪怕是部分内容。

 

带很多复杂参数的内容链接url，有可能被蜘蛛当作重复页面，拒绝收录。

很多动态页面是一个脚本程序带参数体现的，但蜘蛛发现同一个脚本有大量参数的网页，有时候会给该网页的价值评估带来困扰，蜘蛛可能会认为这个网页是重复页面，而拒绝收录。还是那句话，随着技术的发展，蜘蛛对动态脚本的参数识别度有了很大进步，现在基本上可以不用考虑这个问题。

 

但这个催生了一个技术，叫做伪静态化，通过对web服务端做配置，让用户访问的页面，url格式看上去是一个静态页，其实后面是一个正则匹配，实际执行的是一个动态脚本。

 

很多社区论坛为了追求免费搜索来路，做了伪静态化处理，在十多年前，几乎是草根站长必备技能之一。

 

爬虫技术暂时说到这里，但是这里强调一下，有外链，不代表搜索蜘蛛会来爬取，搜索蜘蛛爬取了，不代表搜索引擎会收录；搜索引擎收录了，不代表用户可以搜索的到；

 

site语法是检查一个网站收录数的最基本搜索语法，我开始以为是abc的常识，直到在新加坡做一些创业培训后交流才发现，大部分刚进入这个行业的人，或者有兴趣进入这个行业的人，对此并不了解。

 

一个范例，百度搜索一下 site:4399.com

 

2、索引系统

 

蜘蛛抓取的是网页的内容，那么要想让用户快速的通过关键词搜索到这个网页，就必须对网页做关键词的索引，从而提升查询效率，简单说就是，把网页的每个关键词提取出来，并针对这些关键词在网页中的出现频率，位置，特殊标记等诸多因素，给予不同的权值标定，然后，存储到索引库中。

 

那么问题来了，什么是关键词。

英文来说，比如 this is a book，中文，这是一本书。

英文很自然是四个单词，空格是天然的分词符，中文呢？你不能把一句话当作关键词吧（如果把一句话当作关键词，那么你搜索其中部分信息的时候，是无法索引命中的，比如搜索一本书，就搜索不出来了，而这显然是不符合搜索引擎诉求的）。所以要分词。

 

最开始，最简单的思路是，每个字都切开，这个以前叫字索引，每个字建立索引，并标注位置，如果用户搜索一个关键词，也是把关键词拆成字来搜索再组合结果，但这样问题就来了。

 

比如搜索关键词 “海鲜”的时候，会出现结果，上海鲜花，这显然不是应该的搜索结果。

比如搜索关键词 “和服”的时候，会出现结果，交换机和服务器。

 

这些都是蛮荒期的google也不能幸免的问题。

 

到后来有个梗，别笑，这些都是血泪梗，半夜电话过来，说网监通过搜索发现你社区有淫秽内容要求必须删除，否则就关闭你的网站，夜半惊醒认真排查，百思不得其解，苦苦哀求提供信息线索，最后发现，有人发了一条小广告，“求购二十四口交换机” 。 还有，涉嫌政治敏感，查到最后 “提供三台独立服务器”， 看出其中敏感词了没？你说冤不冤。 这两个故事可能并不是真的，因为都是网上看到的，但是我想说，类似这样的事情真的有，并非都是空穴来风。

 

所以，分词，是亚洲很多语言需要额外处理的事情，而西方语言不存在的问题。

 

但分词不是说说那么简单，比如几点，1：如何识别人名？2、互联网新词如何识别？比如 “不明觉厉”。3、中英混排的坑，比如QQ表情。

 

做一个分词系统，说到底也不难，但是要做一个自动学习，与时俱进，又能高效率灵活的分词引擎，还是很有技术难度的。 当然，这方面我不是专家，不敢妄言了。

 

现在机器学习技术发达了，特别是google在深度学习领域拥有领先优势，以前很多通过人工做标定，做分类的工作可以交给算法完成，从某种意义来说，本地化的工作可以让机器学习去完成；未来，也许深度学习技术可以自己学习掌握本地化的技巧。 但我想说两点，第一，从搜索引擎发展历史看，在深度学习技术还没成熟的情况下，本地化的工作是非常重要的，也是很重要的决定竞争成败的要素；第二，即便现在深度学习已经很强大，基于当地语言的人工参与，标定，测试，反馈，一些本地化的工作依然对深度学习的效率和效果拥有不可替代的作用。

 

索引系统除了分词之外，还有一些要点，比如实时索引，因为一次索引库的更新是个大动静，一般网站运营者知道，自己网站内容更新后，需要等索引库下一次更新才能看到效果，而且索引库针对不同权重的网站内容，更新的频次也不太一样。 但诸如一些高优先的资讯网站，以及新闻搜索，索引库是可以做到近似实时索引的，所以我们在新闻搜索里，几分钟前的信息就已经可以搜索到了。

 

我以前经常吐槽一个事情，我在百度空间发表的文章，每次都是google率先索引收录，当时他们的解释是，猜测是因为很多人通过google阅读器订阅我的博客，而google阅读器很可能是google快速索引的入口。（然并卵，百度空间已经没有了，google阅读器也没有了。）

 

索引系统的权值体系，是所有SEOER们最关心的问题，他们经常通过不同方式组合策略，观察搜索引擎的收录，排名，来路情况，然后通过对比分析整理出相关的策略，这玩意说出来可以开很长一篇了，但今天就不提了。

 

但我说一个事实，很多外面的公司，做SEO的，会误认为百度里面的人熟悉这里的门道和规律，很多人高价去挖百度的搜索产品经理和技术工程师去做SEO，结果，呵呵，呵呵。 而外面那些草根创业者，有些善于此道的，真的比百度的人还清楚，搜索权值的影响关系，和更新频次等等，比如前面说到的，身价几十亿的那个80后创业者。

 

基于结果反推策略，比身在其中却不识全局的参与者，更能找到系统的关键点，有意思不。

 

3、查询展现

 

用户在浏览器或者在手机客户端输入一个关键词，或者几个关键词，甚至一句话，这个在服务端，应答程序获取后处理步骤如下

 

第一步，会检查最近时间有没有人搜索过同样的关键词，如果存在这样的缓存，最快的处理是将这块缓存提供给你，这样查询效率最高，对后端负载压力最低。

 

第二步，发现这个输入查询最近没有搜索，或者有其他条件的原因必须更新结果，那么会将这个用户输入的词，进行分词，没错，如果不止一个关键词，或者是一句话的情况下，应答程序会又一次分词，将搜索的查询拆成几个不同的关键词。

 

第三步，将切分后的关键词分发到查询系统中，查询系统会去索引库查询，索引库是个庞大的分布式系统，先分析这个关键词属于哪一块哪一台服务器，索引是一种有序的数据组合，我们用可以用近似二分法的方式思考，不管数据规模多大，你用二分法去查找一个结果，查询频次是log2(N)，这个就保证了海量数据下，查询一个关键词是非常快非常快的。 当然，实际情况会比二分法复杂很多，这样说比较容易理解而已，再复杂些不是我不告诉大家，是我自己都不是很清楚呢。

 

第四步，不同关键词的查询结果（只是按权值排序的部分顶部结果，绝对不是全部结果），基于权值倒序，会再汇总在一起，然后把共同命中的部分反馈回来，并做最后的权值排序。

 

记住，搜索引擎绝对不会返回所有结果，这个开销谁都受不了，百度也不行，google也不行，翻页都是有限制的。

 

再记住，如果你多个关键词里有多个不同品类冷门词，搜索引擎有可能会舍弃其中一个冷门词，因为汇总数据很可能不包含共同结果。搜索技术不要神话，这样的范例偶尔会出现。

 

这是三大部分，多说一点，其实还有第四部分。

 

用户点击行为采集和反馈部分

 

基于用户的翻页，点击分布，对搜索结果的优劣做判定，并对权值做调整，但这个早期搜索引擎是没有的，后面才有，所以暂时不列为必备的三大块。

 

此外，一些对搜索优化的机器学习策略，对易混词识别，同音词识别等等，相当部分也都基于用户行为反馈进行，这是后话，这里不展开。

 

关于第四部分，我以前说过一个词，点击提权，我说这个词价值千金，我猜很多人并没理解。没理解就好，要不我要被一些同行骂死了。

 

以上是单指搜索引擎的工作原理，和一些技术逻辑，当然，只是入门级的解读，毕竟再深入就不是我能讲解的了。

 

但搜索引擎的本地化，并不局限于搜索技术的本地化。

 

百度的强大，不只是搜索技术，当然有些人会说百度没有搜索技术，这种言论我就不争论了，我不试图改变任何人的观点，我只列一些事实而已。

 

百度的强大还来自于两大块，第一是内容护城河，第二是入口把控。

 

前者是百度贴吧，百度mp3，百度知道，百度百科，百度文库

后者是hao123和百度联盟。

 

这两块都是本地化，google进中国的时候，在这两块都有动作

投资天涯，收购265，以及大力发展google联盟，这些都是本地化。

 

此外，重申一下，百度全家桶的出现以及，百度全家桶和hao123的捆绑，是360崛起之后的事情，hao123从百度收购到360崛起之前，一直风平浪静的没做任何推广和捆绑，从历史事实而言，请勿将本地化等同于流氓化。

第一次认真的把微信小程序的平台文档和测试范例看了一下。

 

别往下看，猜猜我最关心的是看哪部分？

 

是信息模板发送的条款。

 

好吧，从头说起，微信小程序内测的消息一出来，业内就轰动了，请恕我先吐个槽，我觉得微信内测找的那些合作方不太对，按照业务规模排序的一些巨头，当然他们业务量大，应该有优先权，但是他们动作迟缓，公司决策缓慢，你给他们接口，两个月可能都得不到真正有效的反馈，还不如给一些有活力的创业公司，保证俩礼拜啥都鼓捣出来了。

 

对于大部分从业者，都认为微信小程序会成为一个新的分发市场，微信将成为与安卓，谷歌平行的操作系统；当然，也有少部分人不以为然，比如说，他们认为，当年最早做开放接口，试图打造操作系统的社交网络Facebook，如今平台何在？

 

这个扒扒历史，Facebook是最早把开放接口平台做完善的社交网络，也是最早以好友时间线为核心的社交网络平台，而且在当时也是形成了一股极为重要的风气，社交游戏成为一种流行，国内跟风的也很多，Zynga上市更是其中的高潮，但后来问题来了，社交游戏，对原本熟人社交的伤害极大，为了游戏获利的好友关系已经丧失了原来的意义；而时间线也被各种社交游戏的分享所污染。之后Facebook 也开始逐渐着力整顿这一块，而社交游戏的热潮也快速退却，直到现在，近乎销声匿迹。

 

我们说，微信不是很多游戏也有社交功能么？和当年Facebook开放的社交接口相比，其实早就不可同日而语。 存在社交功能的游戏，和以社交为核心的游戏，还是很大不同的。（顺便偷偷说一句，中国互联网社交游戏当年风靡的核心诉求是什么，知道么？是暧昧。嗯，这就不展开了。Facebook最初得以快速发展的核心用户诉求，其实也是暧昧，你信不信。）

 

以前我记得有篇文章提到过，我找不到是哪一篇了，和巨头，大平台合作，要能站在对方角度思考，并理解他们的诉求和目标，理解他们的担心和忧虑，这样你才能找准自己的定位，以及正确的合作姿势。

 

和微信合作也是如此，今年的实际内容其实很简单，罗嗦这些，是希望读者，从历史来体会和思考，微信平台的担忧是什么，我告诉你们，是朋友圈时间线的污染。

 

前几天，我去当面请教俞军，俞军说了一句很经典的点评，微信的成就，来自于控制。那么我的理解，朋友圈，时间线的控制，是这里特别重要的一块，当然还有消息发送的控制。 一旦失去控制，平台就会失去一切。这绝对是张小龙的噩梦。

 

所以，任何，将核心模式和用户获取能力，完全建立在信息分享上的应用，对不起，我肯定的告诉你，没有可能获得微信的平台支持，就算短期你可以绕过审核上线，一旦做大必然被关停。不论是公众号，服务号，还是小程序。这一点，所有在微信平台的开发者，务必要牢记。

 

当然，不是说不可以做分享，但分享必须基于用户主动，自发，无激励，无诱导，无暗示，无混淆的方式。除了分享，消息发送也是如此，用户必须明确自己的行为，会收到什么消息，必须明确，这个消息是自己行为的反馈，（比如付款确认消息，订单完成消息等）。凡是脱离这一基础的，即便侥幸你能绕过审核，一旦做大，未来也会被微信干掉。

 

所以，几点结论

 

第一，不要过度指望流量红利，第一批上线的应用会有流量红利，但不会很多，微信也不会允许你滥用平台流量资源。

 

第二，不要试图做病毒式营销，即便你的玩法很受用户喜欢，一旦被朋友圈刷屏，杀无赦。这样的例子我不用讲，太多太多。

 

第三，理解微信平台的运营思路，比纯粹通过字面理解条款重要，条款是随时可以变更的，而且解释权在微信。

 

第四，市场空间还是有的，但跟APP市场还是会有一些区别。不要顾此失彼。

 

第五，是否有新的市场机会，需要一点想象力。

有想法要开脑洞的，欢迎留言或发信。

 

第六，不论你做什么业务，记住，学会控制是非常重要的一种能力，所谓控制，就是不要为利益，欲望所驱使，失去对真正价值的尊重。

上班了上班了，干活了干活了。

 

那个，其实，我很多年没碰过技术了，但还是觉得有必要把之前一些处理过的技术问题拿出来，其实每个问题，都是很小的问题，如果单独说原因和答案都非常简单，但关键是，遇到问题的思考方式和分析方法。

 

依然是，高手请无视，针对一些初入技术职场的童鞋，希望能对各位遇到问题时候的思考方式有所帮助。

 

案例1：诡异的链接过多

 

当时情况是这样，突然有一天，数据库出现链接过多错误，导致网站报错。 熟悉mysql并操作过高并发系统的朋友知道，数据连接过多属于很常见的问题。但当时的情况是，访问量并不在高峰，按理说不应该有这样的问题。

 

看了一下数据库服务器的负载，很低，并不存在cpu或内存跑满的问题。

慢查询日志没有异常的SQL，更没有锁表。

 

于是就进入数据库做一下 show processlist的查询。

有些朋友可能会问，链接过多你还能看show processlist么，那个，mysql里root比普通用户多一个链接许可，所以，记得程序切忌用root链接，保留一个给系统分析师用。

 

意外发现，几乎所有的SQL停留在sleep状态，而且很多链接都持续了好几秒，甚至十几秒。

 

这里说明一下，如果是用数据中间件链接池来操作，从中间件到数据库存在固定数字的sleep链接是正常的，但从程序端到中间件，除非你是长连接，并且需要保持数据库频繁操作的应用，否则，通常不建议数据库保持连接，也就是不应该出现太多sleep操作。

 

我们的场景就是普通的web应用，php程序而已，都是短链接，按理说，程序执行完就应该释放的，所以这个问题就有点意外。

 

当然，这个和代码的设计也有关系，因为系统用的开源软件改写的，涉及数据库操作还是蛮多的，一般情况下，数据库操作完应该及时关闭，但由于一般认为php代码执行时间很短，所以在代码架构有点复杂的情况下，很多都是默认整个程序执行完再关闭。那么现在问题来了，到底php发生了什么问题。

 

我们去web服务器，看日志，发现访问量并没有异常，也没有针对我们的攻击行为，但确实很多php程序执行时间较长，web连接数也明显多于异常，即便是数据库重启，问题依然会重现，那么这时候，我们工程师就在最常用的php代码里设置断点，去看代码到底卡在哪个环节上执行时间很长，结果，发现是我们的一个非常重要的常识盲点。原来执行时间最长的，是在最后代码数据都执行完，输出执行 echo 的环节。

 

在本地做性能测试，压力测试的时候，我们知道echo 这种语句是基本没有开销的，也不太可能成为一种负载的来源，但这下我们明白了，echo原来不仅仅是php执行输出，也包含了网络传输的时间开销。只有客户端接收到传输内容后，echo执行才结束。

 

而那天的问题，其实是因为同机房有其他公司服务器被Ddos，导致机房出口拥堵，按理说这只是websever的问题，但因为webserver本身有轮询机制，而且设置的连接数较大，虽然访问较慢，但没有崩溃，而因为php代码里mysql链接没有及时释放，在php执行echo的时间等待较长，导致mysql链接过多崩溃。

 

知道这个问题，解决就简单了，因为开源系统封装了输出template的对象，我们就在这个对象执行的时候，先执行mysql_close(); 这样只改了一行代码，问题就解决了。

 

但后来发现出了bug，bug的理由很无厘头，居然部分template 的伪码里有数据库操作，但这个问题解决也简单，因为毕竟这样的场景很少， 而且mysql对象也被封装了，我们就在query方法里加了一行代码，如果没有数据库连接，就重建一个。 这样，这个重建过程只出现在极少数template里有mysql操作的场景，对整体系统基本没有性能干扰。

 

这个案例说来挺简单，就是数据库连接没有及时释放造成的，但因为触动了一个思维盲区，所以印象深刻。

 

线上的程序做断点日志分析是最常用的分析诡异问题的方法。基于断点日志分析，我们可以通过类似二分法，逐步递进直到精确定位具体到每一行代码的执行时间开销。

 

这里还要提醒一个常见问题，线上环境很多问题是在测试环境里很难重现的，所以遇到诡异问题，应该可以在线上做一些日志分析和代码的调试，当然这样可能会有一定的风险，但很多公司的流程和规范，开发工程师只能在线下测试性能和压力承受能力，针对线上很多现实的问题没有办法完整实测。

 

大公司可能会把测试环境做的更好更规范，以及有更有经验的工程师和分析师来解决问题，但创业公司，我建议要给程序员和分析人员一些线上应急处理的权限，否则真的会束手无策，经验值都是靠犯错和解决问题来积累的。

 

案例2：看似正常的负载过高

 

当时有个新业务数据增长很快，该业务的数据库服务器每天处理数百万次数据查询请求，uptime比较高，经常在5-6的样子，cpu负荷较重，运维负责人就发邮件，申请更换更好的服务器，增加资源。

 

按理说，这是个合理请求，负载也确实很高，业务也确实增长，但我这个人天性财迷抠门，总觉得这个数字不应该是极限，就登录到数据库服务器看了一下，很简单，我的方法就是先刷show processlist，连续刷几遍，看数据库都在执行啥，开销都集中在什么状态，这一看还真就发现问题了，居然经常看到有些mysql进程停留在 storing result to query cache 上。

 

这事我就纳闷了，因为按常规，这个状态应该是基本没有时间开销的，也就是show processlist看到是小概率事件的。

 

所以就要验证一下，执行 set profiling=1，然后从show processlist复制一条执行一次，然后执行 show profiles for query 1; 结果意外发现，常规来说执行开销最大的sending data （这个开销可不是输出数据哦，其实是io寻址）只有0.002秒，而 storing result to query cache 却执行了 0.005秒的样子，千分之五秒，一般人可能就无视了吧，但整个SQL执行不到0.01秒，这个开销比例蛮大的了。

 

那个，其实这个问题的责任者呢，是我自己，我觉得query cache是个好东西啊，所以开始配置服务器的时候，还是我自己做的配置，因为服务器内存够大，我就把query cache设置的比较大，结果SQL的反馈结果内容较多的情况下，就出现了query cache的碎片化比较严重，反而导致了query cache存储额外的开销，我在数据库里直接操作将query cache内容重置的命令，再执行这个SQL，用profiling去分析，发现这个开销就没有了，负载瞬间显著下降了60%左右。

 

然后我跟运维负责人说，半夜没人的时候把数据库的启动参数，query cache那块设置回默认值，重启一下数据库，于是就没再追加预算和服务器投入。

 

这个案例本身是我自己的乌龙，因为没有明确理解query cache的读取和存储逻辑，自以为是的调高了参数，在SQL返回值较大的情况下，导致了严重碎片化，带来了额外的开销，虽然每次开销都极其微小，但由于系统的请求频次非常高，所以系统不必要的负载就比较大。

 

那么这个案例里，需要分享的方法是，showprocesslist+一定的敏感度，再配合用set profiling去分析具体的开销，是非常重要的一种分析查询性能的方法。

 

案例3：io性能的优化案例

 

这个案例又是我的错，唉，我发现我犯的错误还是蛮多的，不过我们工程师解决方案非常经典，所以也列在这里以供参考。

 

还是一个非常高并发的业务场景，最开始呢，为了达到查询的最优化，数据结构还是我设计的，使用了复合索引，确保每次查询的索引命中率极高，但这个业务场景有一个问题，就是除了查询请求很高之外，数据的插入请求基本上是同频次的。（大部分场景都是数据插入后随之查询，个别会有单独查询场景），所以插入请求巨大，数据库的io压力特别大。

 

结果我们工程师也是受到我的影响吧，抠门的很，也是尽可能在有限资源下挖潜。结果怎么做的呢? 说来简单，索引降级，把两个字段的复合索引降到单键索引了。

 

单纯从查询而言，这一降级其实是牺牲了效率，但是牺牲的并不大，但从更新而言，从复合索引降级到单键索引，索引更新的io负载就有了明显的降低，由于查询的负载开销远低于更新的负载开销，所以这一降级，在查询与更新同频的场景下，就变得效果特别好。

 

这个案例需要分享的经验是，索引的建立，不但要考虑查询的语句，更新的语句，也要考虑业务场景中相关的频次，在更新频次远低于查询频次时，和更新频次与查询频次相当时，同样的数据结构，同样的SQL语句，可能索引的设计方案会有重大的调整和改变。

 

 

 

 

Mysql也有了很多的版本迭代，很多之前遇到的问题和瓶颈也许现在已经在系统中顺畅解决，但我觉得，一些思路和方法依然值得分享。

 

当然，这些都不是什么高大上的技术和解决方案，都是实战中，屌丝创业团队面临一些实际问题的响应和处理能力。很多草根创业团队，其实都是栽倒类似这样的问题上的。