黑·白

问题

之前涉及的一项工作要求对某些数据做全文索引，并以API向其他内部系统提供搜索查询服务。

由于需要建全文索引的数据量并不大，且已有的数据都以InnoDB引擎存储，简单起见，我们选择MySQL InnoDB引擎的全文索引特性来实现。MySQL从版本5.6开始支持InnoDB引擎的全文索引，不过“从5.7.6版本开始才提供一种内建的全文索引ngram parser，支持CJK字符集（中文、日文、韩文，CJK有个共同点就是单词不像英语习惯那样根据空格进行分解的，因此传统的内建分词方式无法准确的对类似中文进行分词）”，我们使用的MySQL版本为5.6.28，并且需要建全文索引的数据部分是中文，所以这是个问题。

方案

我们先把这项工作按“分治”的思想拆分成几个小问题：

1. 由于版本5.6.28的MySQL不支持中文的全文索引，那么可以对需要建全文索引的数据进行预处理 - 分词，并以空格为间隔将分词结果拼接成一个字符串。
2. 但经过第1步仍是不够的 - MySQL的系统变量ft_min_word_len、ft_max_word_len分别规定了全文检索被编入索引单词的最小长度和最大长度，默认的最小值为4个字符，默认的最大值取决于使用的MySQL版本。为了不改变这个默认值同时也是兼考虑这个值对于英文的意义，则需要通过编码（urlencode、base64、汉字转拼音等）将中文词变长 …

目前工作中开发流程还比较初级，甚至连测试服务器都没有，代码的变更都是直接先在开发人员的本地机器上简单测试一下，然后直接部署到生产服务器上，这就相当于生产服务器同时充当了测试服务器的角色，虽然开发的是面向公司内部的系统，但作为一个有理想有追求的码农，是不允许这样粗糙混乱的开发流程的，所以申请了台服务器，自己搭建个测试服务器。

由于公司的服务器统一使用SUSE Linux Server操作系统，并且版本较老。与Ubuntu、Centos等Linux发行版不同，SUSE Linux没有可用的软件源（不知是否与OpenSUSE的软件源兼容？），即没法使用系统的软件包管理工具。这样问题就很多了。

我选择源码编译的方式来安装所有涉及的软件。也许有人会说，为什么不在网络上查找RPM包然后安装呢？那么先想一下RPM包本质上是个什么东西呢？RPM包（以及DEB包）其实就是将编译好的一些程序以一定的规则打包在一起，然后系统的包管理工具（yum、zypper）按照相同的规则（在依赖满足的情况下）将RPM包里文件复制到指定好的目录里。如果RPM包的依赖没有解决，是无法成功安装的。即使安装好了，若程序依赖的动态链接库等不存在或版本不匹配，也是无法正确运行的，比如libc库的版本过低，但明显你不能轻易替换libc库，因为系统中已安装的很多程序都依赖于libc库。那么相比源码编译方式，RPM包方式的问题更难解决。

需要安装的软件有Nginx、PHP、MySQL、Memcached、Redis、Mongodb …

MySQL逻辑架构

1. 每个客户连接在服务器进程中都拥有自己的线程，每个连接所属的查询都会在指定的某个单独线程中完成，这些线程轮流运行在某个CPU核心或CPU上。服务器负责缓存线程，因此不需要为每个新的连接重建或撤销线程。

2. MySQL会解析查询，并创建一个内部数据结构(解析树)，然后对其进行各种优化。其中包括重写查询，决定查询的读表顺序，以及选择需使用的索引等。用户可以通过特殊的关键字给优化器传递各种提示，影响它的决策过程。另外还可以请求服务器给出优化过程的各种说明，使用户可以知晓服务器是如何进行优化决策的，为用户提供一个参考基准，方便用户重写查询、架构和修改相关配置，便于应用尽可能高效地运行。

优化器并不关心某个表使用哪种存储引擎，但存储引擎对服务器的查询优化过程有影响。优化器会请求存储引擎为某种具体操作提供性能与开销方面的信息，以及表内数据的统计信息。

不过，在解析查询之前，服务器会"询问"查询缓存，它只能保存SELECT语句和相应的结果。如果能在缓存中找到将要执行的查询，服务器就不必重新解析、优化或重新执行查询，只需直接返回已有结果即可。

并发控制

1. 读锁(Read Lock)/写锁(Write Lock)：并发控制的概念很简单-在处理并发写或并发读时，系统会使用一套锁系统来解决问题。这种锁系统由两类锁组成，通常称之为 共享锁 …