When Does Standard 1C-Bitrix Search Start to Slow Down?

The built-in search in 1C-Bitrix uses tables b_search_content, b_search_content_stem, and b_search_stem. For a catalog of 30,000 items, full re-indexing takes 4–12 hours, the agent CSearchIndex::IndexAgent runs continuously, and search quality remains low: stemming fails with Russian morphology, relevance does not account for sales. Our experience shows that proper tuning reduces indexing time by 50–80% and improves result accuracy by 30–40%. We have been working with Bitrix for over 10 years and guarantee results. The problem worsens when multiple modules are active on the site—each extra module adds 15–20% to the index table size. A typical scenario: an admin enables search for forums, blogs, and documents, although users only need the product catalog. The index bloats, queries slow down, and the agent cannot keep up with changes.

Diagnosing Current Indexing

First, we check the state of index tables:

SELECT table_name, ROUND(data_length / 1024 / 1024, 2) AS data_mb, ROUND(index_length / 1024 / 1024, 2) AS index_mb, table_rows FROM information_schema.TABLES WHERE table_schema = DATABASE() AND table_name LIKE 'b_search%' ORDER BY data_length DESC; 

The b_search_content_stem table on a large portal can occupy 2–5 GB. OPTIMIZE TABLE for it blocks queries for hours—we only do it during a maintenance window.

How to Configure Indexing Parameters?

In the administrative interface (Settings → Search → Settings), we change key parameters:

1. Minimum word length — increase from 2 to 3–4. Two-letter words clutter the index and carry no search value.
2. Stop words — add prepositions, conjunctions, articles. For a Russian-language site, the basic list includes 50–80 words.
3. Indexed modules — disable modules whose search is not needed by users (forums, blogs, document workflow).
4. Number of elements per agent run — optimally 50–100.

// In search module settings or via agent CSearch::ReIndex($moduleId, $start, $finish, $step = 50); 

Incremental vs. Full Indexing

Full re-indexing (ReIndexAll) is only for initial setup or after major catalog structure changes. In normal operation, incremental indexing via agent should work. Problem: the agent CSearchIndex::IndexAgent triggers on any change of DATE_CHANGE. During synchronization with 1C, the date changes even if content hasn't—the agent effectively re-indexes the entire catalog every time. Solution: compare hash of significant fields before and after update. Update DATE_CHANGE only on actual change:

$oldHash = md5($oldElement['NAME'] . $oldElement['DETAIL_TEXT'] . implode(',', $oldProperties)); $newHash = md5($newElement['NAME'] . $newElement['DETAIL_TEXT'] . implode(',', $newProperties)); if ($oldHash !== $newHash) { // Update with DATE_CHANGE change } else { // Update stock/prices without triggering re-indexing $DB->Query("UPDATE b_iblock_element SET TIMESTAMP_X = TIMESTAMP_X WHERE ID = {$id}"); } 

MySQL FULLTEXT vs. Elasticsearch: Which to Choose?

If your catalog has up to 30,000 items and you need simple search, optimizing FULLTEXT is enough. For 50,000+ and complex filters, better use Elasticsearch.

Cleaning Stale Index Records

On live sites, b_search_content accumulates records of deleted items. We clean in batches of 1000 via agent or cron—never run a single DELETE on 100,000 in production:

-- Find records of deleted iblock elements SELECT sc.ID, sc.PARAM1, sc.PARAM2 FROM b_search_content sc LEFT JOIN b_iblock_element ie ON ie.ID = CAST(sc.PARAM1 AS UNSIGNED) WHERE sc.MODULE_ID = 'iblock' AND ie.ID IS NULL LIMIT 10000; 

What's Included in Search Optimization?

• Diagnostics of current indexes and search module settings
• Configuration of stop words, minimum word length, exclusion of unnecessary modules
• Optimization of incremental indexing agent (field hashing)
• MySQL FULLTEXT tuning (my.cnf: innodb_ft_min_token_size, stopword table)
• Cleaning garbage from indexes
• Monitoring of zero-result queries (b_search_log)
• Documentation with recommendations and support procedures

Monitoring Search Quality

After optimization, we enable logging of queries that return zero results. Zero-result queries signal need for content expansion or migration to Elasticsearch.

Case Study: 4x Reduction in Indexing Time

Client — an online auto parts store (40,000 items). Full indexing took 8 hours, the agent kept CPU load at 70–90%. After configuring incremental indexing with hashing and optimizing FULLTEXT, full traversal time dropped to 2 hours, CPU load to 15–20%. Search quality improved: zero-result queries decreased by 35%. Budget savings on cloud resources amounted to about 400,000 RUB per year.

Typical Mistakes in Search Configuration

• Setting minimum word length to 1: index fills with garbage, search slows down.
• Full re-indexing every night: unnecessary load; incremental is sufficient.
• Ignoring stop words: search finds articles with prepositions instead of needed products.
• No monitoring: zero-result queries remain unnoticed, content not enriched.

Result

Optimizing parameters and indexing strategy reduces full traversal time by 50–80%, lowers agent load to background levels, and improves relevance. Contact us to get a consultation and work plan. Order a search audit — we will evaluate your project in one day.