In depth analysis of php sphinx

< ?php
// Parameter filtering

/ / filter cat_id = 2
$cl- > SetFilter("cat_id",array(2));
// Search only in id subforum 1, 3, 7
$cl- > SetFilter("forum_id",array(1,3,7));

// Scope filtering
// The filter release time is today and the parameter is int timestamp
$cl- > SetFilterRange("starttime",123,124);
// Filter the price
$cl- > SetFilterRange("price",10.0,99.9);

/ / group
// Grouped by item_id and sorted by order desc
$cl- > SetGroupBy("item_id",SPH_GROUP_ATTR,"order desc");

// Sort mode
// Sort by price desc
$cl- > SetSortMode(SPH_SORT_ATTR_DESC,"price");
Note: this will be overridden by the sort in SetGroupBy

Matches any 1 of the query words
$cl- > SetMatchMode ( SPH_MATCH_ANY );
SPH_MATCH_ALL, matching all query words (default mode);
SPH_MATCH_ANY, matching any one of the query words;
SPH_MATCH_PHRASE, the whole query as 1 phrase, required complete matching in order;
SPH_MATCH_BOOLEAN, which treats the query as a Boolean expression (see Section 5.2 "Boolean Query Syntax");
SPH_MATCH_EXTENDED, which treats the query as an expression of the CoreSeek/Sphinx internal query language (see Section 5.3 "Extended Query syntax"). Starting with version Coreseek 3/Sphinx 0.9.9, this option is replaced by the option SPH_MATCH_EXTENDED2, which provides more functionality and better performance. This option is kept to be compatible with legacy old code -- so that the old application code will continue to work even as Sphinx and its components, including API, are upgraded.
SPH_MATCH_EXTENDED2, using version 2 of the Extended Matching Pattern to match the query.
SPH_MATCH_FULLSCAN, which forces the "full scan" pattern described below to match the query. Note that in this mode, all query words are ignored, and while filters, filter ranges, and groupings are still in effect, no text matches occur.

// Start from 0, query 30, return results up to 1000
$cl- > setLimits(0,30,1000);

// Search "movie tickets" from sphinx index
$cl- > Query(" Tickets ","index");

// Search "movie tickets" from sphinx index index
$sp- > SetGroupBy('item_id',SPH_GROUP_ATTR,'s_order desc');
$sp- > SetFilter('city_id','1');
$sp- > SetFilter('cat_id',array(1));
$sp- > SetLimit(0,10,1000);
$sp- > AddQuery(' cinema ticket ','index');
$sp- > ResetFilters (); // Reset the filter
$sp- > ResetGroupBy (); // Reset grouping

$sp- > SetGroupBy('item_id', SPH_GROUPBY_ATTR, 's_order desc');
$sp- > setFilter('city_id', '2');
$sp- > setFilter('cat_id', array(2));
$sp- > setLimits(0, 20, 1000);
$sp- > AddQuery(' hot springs ', 'index');
$sp- > ResetFilters (); // Reset the filter
$sp- > ResetGroupBy (); // Reset grouping
$results = $sp- > RunQuries();
Bulk queries (or multiple queries) enable searchd to perform possible internal optimizations and reduce the overhead of network connections and process creation in any case. Bulk queries introduce no additional overhead compared to individual queries. So when your Web page runs several different queries, 1 should definitely consider using bulk queries.
For example, running the same full-text query multiple times, but with different sort or grouping Settings, would cause searchd to run expensive full-text retrieval and relevance calculations only once, and then generate multiple grouping results on top of that.
Sometimes you need to display not only the search results but also some category-related counting information, such as the number of products grouped by manufacturer, when bulk queries can save a lot of overhead. Without batch queries, you would have to run these essentially identical queries many times and fetch the same matches, resulting in different result sets. With batch queries, you simply combine these queries into a single batch query, and Sphinx internally optimizes these redundant full-text searches.
AddQuery() stores all current Settings and queries internally, and you can change Settings in subsequent AddQuery() calls. Previously added queries will not be affected, and there is virtually no way to change them.

Using this code, the first query will look up "hello world" on the "documents" index and sort the results by relevance, the second query will look up "ipod" on the "products" index and sort the results by price, and the third query will look up "harry potter" on the "books" index and sort the results by price. Note that the second call to SetSortMode() does not affect the first query (because it has already been added), but the next two queries will be affected.
In addition, any filtering that was set before AddQuery() will be continued by subsequent queries. Therefore, if you use SetFilter() before the first query, the same filtering applies to the second query (and subsequent batch queries) executed by AddQuery(), unless you call ResetFilters() first to clear the filtering rule. At the same time, you can always add new filtering rules
AddQuery() does not modify the current state. That is, all the existing sorting, filtering, and grouping Settings will not change with this call, so subsequent queries can easily reuse the existing Settings.
AddQuery() returns 1 index in the array returned by the RunQueries() result. It is an increasing integer starting at 0, that is, the first call returns 0, the second return 1, and so on. This handy feature lets you avoid having to record the subscripts manually when you need them.
? >