For information blocks containing quite a lot of elements, it would be appropriate to use a separate table storage mode (the "Information Blocks 2.0" technology). Notice that such change will not require any modification of the source code: all you have to do is to switch to another storage mode.

This technology reduces database load, makes SQL queries less complex and verbose, decreases table merge operations. In fact, each information block with a unique set of properties has an individual SQL table.

If you expect a high frequency of queries with known properties to some information blocks, you can make queries to such information blocks even more fast by adding indexes for the respective properties.

Even with all the possible improvements, you should not forget about routine manual optimization which will also add to the overall database performance. To optimize the database tables and indexes, use the form "Settings > Tools > Optimize Database".

How to perform the test?

1. When designing the system, pick out the information blocks that will use a separate table storage mode.
2. Gather the statistics and determine the properties that are most frequently used in the database queries.

   Now check the information block property storage table for the presence of property indexes. Open "Content > Information Blocks > Information Block Types", select a required information block and click the "Properties" tab. Find the binding property ID. Then, click the "Information Block" tab and find the information block ID. Now find ("show create table ") a database table that keeps the property values; the tables have names in format "b_iblock_element_prop_s#information_block_ID#", for example "b_iblock_element_prop_s1" (the "s" tables keep scalar values; the "m" tables keep multiple values).

   Now check that an index exist for each of intended properties. Execute the following query in "Settings > Tools > SQL Qiery" (MySQL example):

   show create table b_iblock_element_prop_s1

   This will return a table structure, for example:
   CREATE TABLE `b_iblock_element_prop_s1` ( `IBLOCK_ELEMENT_ID` int(11) NOT NULL, `PROPERTY_11` text collate utf8_unicode_ci, `DESCRIPTION_11` varchar(255) collate utf8_unicode_ci default NULL, `PROPERTY_12` decimal(18,4) default NULL, `DESCRIPTION_12` varchar(255) collate utf8_unicode_ci default NULL, `PROPERTY_13` int(11) default NULL, `DESCRIPTION_13` varchar(255) collate utf8_unicode_ci default NULL, `PROPERTY_14` int(11) default NULL, `DESCRIPTION_14` varchar(255) collate utf8_unicode_ci default NULL, PRIMARY KEY (`IBLOCK_ELEMENT_ID`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

   In this case, the binding property is in the "PROPERTY_13" column. As you can see, there is only one key so far:
   "PRIMARY KEY (`IBLOCK_ELEMENT_ID`)".

   Add a column index:
   alter table b_iblock_element_prop_s1 add index ix_prop13 (PROPERTY_13)

   Now execute "show create table b_iblock_element_prop_s1". You will see the new index added:
   KEY `ix_prop13` (`PROPERTY_13`)

   To get the table index details, execute "show indexes in b_iblock_element_prop_s1".

   Indexes for the multiple property tables can be created in a similar way. Check that indexes exist for all heavily used properties.
3. Ensure that the database tables are optimized manually using the form "Settings > Tools > Optimize Database", or automatically using any system administration software. The frequency of optimization depends on the size and volatility of data.