sphinx配置分析
type：数据源类型
数据源类型。必须选项，无默认值。 可用的类型包括 mysql, pgsql, mssql, xmlpipe and xmlpipe2, odbc，以及python.
sql_host：数据库服务器
要连接的SQL服务器主机地址。必须选项，无默认值。仅对SQL数据源（mysql, pgsql, mssql）有效。
最简单的情形下，Sphinx与MySQL或PostgreSQL服务器安装在同一台主机上，此时您只须设置为localhost即可。注意，MySQL客户端库根据主机名决定是通过TCP/IP还是UNIX socket连接到服务器。一般来说，“localhost”使之强制使用UNIX socket连接（这是默认的也是推荐的模式），而“127.0.01”会强制使用TCP/IP。细节请参考 MySQL manual
sql_port：数据库端口
要连接的SQL服务器的IP端口。可选选项，默认值为mysql端口3306，pgsql端口5432。仅适用于SQL数据源（mysql, pgsql, mssql）。注意，此选项是否实际被使用依赖于sql_host选项。
sql_pass:数据库密码
连接到SQL数据源之后使用的SQL数据库，此后的查询均在此数据库上进行。必须选项，无默认值。 仅适用于SQL数据源（mysql, pgsql, mssql）。
sql_sock：数据库Socket文件
连接到本地SQL服务器时使用的UNIX socket名称。可选选项，默认值为空（使用客户端库的默认设置）。 仅适用于SQL数据源（mysql, pgsql, mssql）。
在Linux上，通常是/var/lib/mysql/mysql.sock。 而在FreeBSD上通常是/tmp/mysql.sock。注意此选项是否实际被使用依赖与sql_host的设置。
示例：
sql_sock = /tmp/mysql.sock
MySQL客户端的连接标志（connection flags）。可选选项，默认值为0（不设置任何标志）。仅适用于mysql数据源。
此选项必须包含各标志相加所得的整型值。此整数将被原样传递给mysql_real_connect() 。 可用的标志在mysql_com.h中列举。下面列举的是几个与索引相关的标志和它们的值：
- CLIENT_COMPRESS = 32; 允许使用压缩协议 protocol
- CLIENT_SSL = 2048; 握手后切换到SSL
- CLIENT_SECURE_CONNECTION = 32768; 新的MySQL 4.1版本身份认证
例如，标志2080（2048+32）代表同时使用压缩和SSL，32768代表仅使用新的身份验证。起初这个选项是为了在indexer和mysql位于不同主机的情况下使用压缩协议而引入的。尽管降低了网络带宽消耗，但不管在理论上还是在现实中，在1Gbps的链路上启用压缩很可能恶化索引时间。然而在100Mbps的连输上启用压缩可能会明显地改善索引时间（有报告说总的索引时间降低了20-30%）。根据您网络的连接情况，您获得的改善程度可能会有所不同。
示例：
mysql_connect_flags = 32 # 启用压缩
mysql_ssl_cert, mysql_ssl_key, mysql_ssl_ca：MySQL的SSL连接
连接MySQL服务器时使用的SSL认证选项。可选参数，默认值是空串（即不使用SSL认证）。 仅适用于mysql数据源。
这些指令用来在indexer和MySQL之间建立安全的SSL连接。关于怎样建立认证机制和设置MySQL服务器的信息可以参考MySQL文档。
示例：
mysql_ssl_cert = /etc/ssl/client-cert.pem mysql_ssl_key = /etc/ssl/client-key.pem mysql_ssl_ca = /etc/ssl/cacert.pem
odbc_dsn：ODBC连接字符串(DSN)
要连接的ODBC DSN。必须选项，没有默认值。 仅适用于odbc数据源。
DBC DSN（数据源名字，Data Source Name）指定了连接ODBC数据源时使用的认证选项（主机地址，用户名，密码等）。具体的格式与ODBC的具体驱动有关。
示例：
odbc_dsn = Driver={Oracle ODBC Driver};Dbq=myDBName;Uid=myUsername;Pwd=myPassword
sql_query_pre：待索引数据获取前查询
索引数据获取前执行的查询（pre-fetch query），或预查询（pre-query）。多值选项，可选选项，默认为一个空的查询列表。 仅适用于SQL数据源（mysql, pgsql, mssql）。
多值意思是您可以多次设置该指令，从而指定多个预查询。它们在索引数据获取查询sql_query之前执行，而且会严格按照在配置文件中出现的顺序执行。预查询的结果会被忽略。
预查询在很多时候有用。它们被用来设置字符集编码，标记待索引的记录，更新内部计数器，设置SQL服务器连接选项和变量等等。
也许预查询最常用的一个应用就是用来指定服务器返回行时使用的字符编码。这必须与Sphinx期待的编码相同（在charset_type 和charset_table 选项中设置）。以下是两个与MySQL有关的设置示例：
sql_query_pre = SET CHARACTER_SET_RESULTS=cp1251 sql_query_pre = SET NAMES utf8
对于MySQL数据源，在预查询中禁用查询缓冲（query cache）（仅对indexer连接）是有用的，因为索引查询一般并会频繁地重新运行，缓冲它们的结果是没有意义的。这可以按如下方法实现：
sql_query_pre = SET SESSION query_cache_type=OFF
示例：
sql_query_pre = SET NAMES utf8 sql_query_pre = SET SESSION query_cache_type=OFF
sql_query：获取待索引数据查询
获取即将索引的文档（数据）的主查询。必须的选项，无默认选项。 仅适用于SQL数据源（mysql, pgsql, mssql）。
只能有一个主查询。它被用来从SQL服务器获取文档（文档列表）。可以指定多达32个全文数据字段（严格来说是在sphinx.h中定义的SPH_MAX_FIELDS个）和任意多个属性。所有既不是文档ID（第一列）也不是属性的列的数据会被用于建立全文索引。
文档ID必须是第一列，而且必须是唯一的正整数值（不能是0也不能是负数），既可以是32位的也可以是64位的，这要根据Sphinx是如何被构建的，默认情况下文档ID是32位的，但在运行configure脚本时指定--enable-id64选项会打开64位文档ID和词ID的支持。
示例：
sql_query = \ SELECT id, group_id, UNIX_TIMESTAMP(date_added) AS date_added, \ title, content \ FROM documents
连接/有效载荷字段获取查询。 多值选项，可选，默认值为空。 仅对SQL数据源有效 (mysql, pgsql, mssql) .
sql_joined_field 提供两种不同的方式：连接字段，或者有效载荷（有效载荷字段）。其语法格式如下：
sql_joined_field = FIELD-NAME 'from' ( 'query' | 'payload-query' ); \
QUERY [ ; RANGE-QUERY ]
where
- FIELD-NAME 是 连接/有效载荷 字段名称;
- QUERY 是一个用于获取数据到索引的SQL查询.
- RANGE-QUERY 是一个可选的用于获取范围知道索引的SQL查询. (版本2.0.1-beta增加.)
Joined fields let you avoid JOIN and/or GROUP_CONCAT statements in the main document fetch query (sql_query). This can be useful when SQL-side JOIN is slow, or needs to be offloaded on Sphinx side, or simply to emulate MySQL-specific GROUP_CONCAT funcionality in case your database server does not support it.
The query must return exactly 2 columns: document ID, and text to append to a joined field. Document IDs can be duplicate, but they must be in ascending order. All the text rows fetched for a given ID will be concatented together, and the concatenation result will be indexed as the entire contents of a joined field. Rows will be concatenated in the order returned from the query, and separating whitespace will be inserted between them. For instance, if joined field query returns the following rows:
( 1, 'red' ) ( 1, 'right' ) ( 1, 'hand' ) ( 2, 'mysql' ) ( 2, 'sphinx' )
then the indexing results would be equivalent to that of adding a new text field with a value of 'red right hand' to document 1 and 'mysql sphinx' to document 2.
Joined fields are only indexed differently. There are no other differences between joined fields and regular text fields.
Starting with 2.0.1-beta, ranged queries can be used when a single query is not efficient enough or does not work because of the database driver limitations. It works similar to the ranged queries in the main indexing loop, 参见 第 3.7 节 “区段查询”. The range will be queried for and fetched upfront once, then multiple queries with different$start and $end substitutions will be run to fetch the actual data.
Payloads let you create a special field in which, instead of keyword positions, so-called user payloads are stored. Payloads are custom integer values attached to every keyword. They can then be used in search time to affect the ranking.
The payload query must return exactly 3 columns: document ID; keyword; and integer payload value. Document IDs can be duplicate, but they must be in ascending order. Payloads must be unsigned integers within 24-bit range, ie. from 0 to 16777215. For reference, payloads are currently internally stored as in-field keyword positions, but that is not guaranteed and might change in the future.
Currently, the only method to account for payloads is to use SPH_RANK_PROXIMITY_BM25 ranker. On indexes with payload fields, it will automatically switch to a variant that matches keywords in those fields, computes a sum of matched payloads multiplied by field wieghts, and adds that sum to the final rank.
示例：
sql_joined_field = \
tagstext from query; \
SELECT docid, CONCAT('tag',tagid) FROM tags ORDER BY docid ASC