Sphinx Search for 1C-Bitrix: Setup, Morphology, and Delta-Indexation

Why standard Bitrix search fails with a large catalog?

A catalog of 200,000 items — the standard Bitrix search returns a page in 5 seconds, filtering by properties takes even longer. The standard search module uses b_search_* tables, which are not optimized for complex filtering by multiple properties or full-text search with morphology. Sphinx solves both problems: incremental indexing, morphology, and faceted search. We configure it turnkey in 3–10 days. The engine reads data directly from MySQL, simplifying integration: you don't need to write an exporter — the data source is described via SQL queries in the Sphinx config.

For example, in an auto parts e-commerce project with a catalog of 350,000 items, after deploying Sphinx, search time dropped from 8 seconds to 50 ms, and filtering by 12 properties became instant. We have implemented Sphinx in 30+ Bitrix projects with catalogs ranging from 10,000 to 500,000 items. We guarantee stable operation and post-launch support. Contact us — we will work out the search architecture for your project.

How to configure the data source for Sphinx?

Sphinx reads data via a source — an SQL query executed during reindexing. Example config for a product catalog:

source bitrix_catalog { type = mysql sql_host = localhost sql_user = bitrix sql_pass = password sql_db = bitrix_db sql_port = 3306 sql_query = \ SELECT \ e.ID, \ e.IBLOCK_ID, \ e.NAME, \ e.DETAIL_TEXT, \ e.CODE, \ UNIX_TIMESTAMP(e.TIMESTAMP_X) AS updated_at \ FROM b_iblock_element e \ WHERE e.IBLOCK_ID IN (5, 6) \ AND e.ACTIVE = 'Y' \ AND e.WF_STATUS_ID = 1 sql_attr_uint = IBLOCK_ID sql_attr_uint = updated_at sql_field_string = NAME } 

sql_attr_uint declares numeric attributes for filtering, sql_field_string declares a string field for search and display. Sphinx supports up to hundreds of attributes without performance loss.

Connecting product properties for faceted filtering

For faceted filtering, add properties via sql_attr_multi:

sql_attr_multi = uint PROPERTY_COLOR FROM query; \ SELECT e.ID, p.VALUE_NUM \ FROM b_iblock_element e \ JOIN b_iblock_element_prop_s5 p ON p.IBLOCK_ELEMENT_ID = e.ID \ WHERE e.IBLOCK_ID = 5 

The table b_iblock_element_prop_s5 corresponds to infoblock ID 5. This is a Bitrix feature: each infoblock has its own property table. In complex projects, we combine several tables via UNION. You can also index multiple properties via sql_attr_multi with delimiters, enabling filtering by several values simultaneously.

How to configure Russian morphology?

Sphinx supports Russian via a built-in stemmer. Index configuration:

index bitrix_catalog { source = bitrix_catalog path = /var/lib/manticore/bitrix_catalog morphology = stem_ru, stem_en min_word_len = 2 charset_table = 0..9, A..Z->a..z, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F min_prefix_len = 3 } 

min_prefix_len = 3 enables prefix search: "ноут" → "ноутбук". This increases the index, but we always optimize for your data volume. For large catalogs (over 300,000 items) we recommend dropping prefix and using infix search. The charset_table setting ensures correct Cyrillic handling and case insensitivity.

PHP client and queries from Bitrix

Sphinx uses the MySQL protocol, so we access it via PDO:

$sphinx = new PDO('mysql:host=127.0.0.1;port=9306', '', ''); $stmt = $sphinx->prepare( "SELECT id, weight() as w, NAME FROM bitrix_catalog WHERE MATCH(:query) AND IBLOCK_ID = :iblock ORDER BY w DESC LIMIT :offset, :limit OPTION max_matches=1000" ); $stmt->execute([ ':query' => $searchQuery, ':iblock' => CATALOG_IBLOCK_ID, ':offset' => ($page - 1) * $pageSize, ':limit' => $pageSize, ]); $ids = array_column($stmt->fetchAll(), 'id'); 

Once you have $ids, load full data via CIBlockElement::GetList(). This is the standard pattern we use in all projects. To speed up, you can cache the result IDs for 5–10 minutes. For high query volumes, we recommend a PDO connection pool.

How to set up delta-indexation for up-to-date data?

Full reindexation (indexer --all) — for nightly cron tasks. Delta index — indexes only records changed since the last indexation. Requires an updated_at field and a separate source:

source bitrix_catalog_delta : bitrix_catalog { sql_query = \ SELECT e.ID, ... \ FROM b_iblock_element e \ WHERE UNIX_TIMESTAMP(e.TIMESTAMP_X) > (SELECT max_doc_date FROM sph_counter WHERE id=1) } 

Merge: indexer --merge bitrix_catalog bitrix_catalog_delta. Delta-indexation runs every 5–10 minutes via cron. We also configure sph_counter to correctly track the last indexation time. If cron fails, a full reindexation runs automatically.

Why Sphinx and not Elasticsearch?

Sphinx indexes data from MySQL 2–3 times faster on servers with 2 CPU and 4 GB RAM. Comparison for a typical Bitrix catalog:

Choose Sphinx if your server has < 4 GB RAM and data comes only from MySQL. Elasticsearch is better for clusters and real-time aggregations. In 80% of our Bitrix projects, we use Sphinx. Learn more about Sphinx on Wikipedia.

What typical errors occur when setting up Sphinx?

The most common is an incorrect charset_table: if Cyrillic is not specified, searches for Russian words return empty results. The second most common is missing sql_attr_multi for properties: faceted filtering stops working. The third is a too large min_prefix_len: for catalogs >500,000 items, the index grows 2–3 times and indexing time increases. In every project, we audit the configuration and perform load testing to eliminate these issues.

What is included in the integration

• Analysis of catalog structure and search requirements
• Deploy Sphinx (Manticore) on the server
• Configure data sources (infoblocks, properties, hl-blocks)
• Set up indexes with morphology and prefix search
• Develop a PHP gateway for queries from Bitrix
• Integrate with the catalog component (faceted search, filter)
• Implement delta-indexation (data freshness)
• Test under load
• Documentation and administrator training
• 12-month warranty on all work

Timelines and pricing

Pricing is calculated individually after analyzing your project. We assess data volume, facet complexity, and speed requirements. Order the integration — get a consultation on search architecture. Certified specialists with 7+ years of experience guarantee stable operation and post-launch support.