When is the best time for Oracle to create an index

Introduction: The database is based on the index of the Oracle database, and the relevant statements can quickly locate the location of the record without having to locate the entire table, which is convenient and fast, and greatly improves the work efficiency of the staff.

Although it is said that whether to create an index in the table will not affect the use of the Oracle database, nor will it affect the use of database statements. It's as if the user can still use the dictionary even if it doesn't have a directory. However, if the dictionary does not have a directory, it is conceivable that if a user wants to look up an entry, he has to go through the entire dictionary. The same goes for databases. If no relevant index is established, the database has to query the entire table when querying records. When there are many records in the table, the query efficiency will be very low. Therefore, a suitable index is a good tool to improve the efficiency of database operation.

However, it is not to say that the more indexes on the table, the better. More than that. Therefore, in the process of database design, it is still necessary to select some suitable indexes for the table. It is better to be short than to waste, this is a standard to follow when building an index. In theory, although a table can have unlimited indexes. However, database administrators need to know that the more indexes on a table, the more expensive it is to maintain the indexes. Whenever the records in the data table are added, deleted, or updated, the database system needs to update all indexes. Therefore, the index in the database table is definitely not the more the better. Specifically, on the index establishment, the author has the following suggestions for everyone.

Recommendation 1: Be good at using bitmap indexes on fields with small cardinality.

Cardinality is a basic definition in a bitmap index, which refers to a non-repeated value in the content of a field in a database table. For example, the gender field in the employee information table generally has only two values, male and female, so its cardinality is 2; for the marital status field, there are only three states of married, unmarried, and divorced, and its cardinality is 3 ;There are only a few values ​​in the national list.

For a field with a small cardinality to be queried, such as when a user wants to find all "women" whose marital status is "married", using a bitmap index can improve the efficiency of the query. This is mainly because the standard index is implemented by storing the sorted index column and the corresponding ROWID in the index. If we build a standard index on a column with a small cardinality, it will return a large number of records.

When we create a bitmap index, Oracle will scan the entire table and create a bitmap for each value of the index column. If the content is the same, it will be represented by the same number on the bitmap. At this time, if the cardinality of this field is relatively small, the efficiency will be very high if you need to query the entire field. Because at this time, the database only needs to find out the content with the same number in the bitmap.

In addition to using a bitmap index when the cardinality of a column in the data table is relatively small, we often recommend using a bitmap index in some special cases. The most common situation is that in the Where restriction condition, if we use AND or OR condition multiple times, it is also recommended to use bitmap index. Because when a query consumes some columns with bitmap indexes deployed, these bitmaps can be easily combined with AND or Or operators to quickly find the records the user needs.

However, it should be noted here that using a bitmap index can provide higher efficiency when the operator is not included in the conditional statement. In general, bitmap indexing is advantageous only when AND or OR operators are used. If the user uses the greater-than sign or the not-equal sign as the restriction in the conditional statement, it is often more advantageous to use the standard index.

Therefore, in the database settings, the author generally uses bitmap indexes only in three cases. One is that the cardinality of the column is relatively small, and it may be necessary to search for related records based on the content of these fields; the other is when the AND or OR operator is used in the conditional statement. In addition to these two cases, it is best to use other suitable indexes. The third case is that you need to use NULL as a query constraint. Because standard queries generally ignore all NULL value columns. That is to say, if you need to query the information of "all employees without ID numbers", the standard index cannot play a role in speeding up the query. In this case, bitmap indexing is required. Because the bitmap index will record the relevant NULL value column information.

Recommendation 2: Some restrictions on creating indexes.

Not to say, the more indexes a table or column has, the better. On the contrary, the more indexes are built, sometimes it will affect the overall performance of the database operation. Therefore, there are still some restrictions when creating an index.

One is not to index some tables with few records. When designing an application system, such as designing a database of an ERP system, there are thousands of tables. However, not every table has a large number of records. On the contrary, nearly half of the data tables may not store more than 100 pieces of data. Such as employee login account password table, enterprise department information table and so on. For these tables with relatively few records, it is best not to create indexes for them. Whether it is on the table or on the field, do not create an index.

The second is that if the content in the table is relatively large, but the table is basically not queried, you only need to build an index on the table; you don't need to build an index on the field. For example, in the ERP system now, there is a table called "AD_Table". It stores information about related tables in this database. This table is only used during database design. Therefore, although there are many records in this table, because users use it less, it is generally not necessary to establish a column-level index for this table. Instead, use the table index directly.

Third, on some NULL fields, it is necessary to judge whether to build an index according to the actual situation. For example, there is a form of personnel file with two fields on it, namely "ID number" and "region". Sometimes, for some reason, companies need all employees to register their ID numbers in the system to facilitate their payroll, social security, and so on. Therefore, personnel management may need to frequently query the system to see if there is any employee information without an ID number. At this point, we need to use the condition "IS NULL" to query the records we need. Therefore, in order to improve the query efficiency, if a record may be empty, and it is often necessary to query with NULL as a condition, it is better to add an index to this field, and it is better to establish a bitmap index. On the contrary, if the condition of NULL may be used as the limit statement of the query, but it is not used a lot, there is no need to create an index for it.

Recommendation 3: Index design for multi-table join queries.

If there is a personnel management system now. The HR manager wants to know the employee's social security contributions. He needs to know the employee's name, position, the nature of the household registration (the fee for a farmer's household registration is different from that of a resident's household registration), the payment status, and so on. However, this information is contained in different tables. Because in order to improve the performance of the database, only some serial numbers may be stored in the table, rather than the specific content. For example, in the social security table, the number corresponding to the employee is stored instead of the employee's name. Therefore, if you want to get this report, you may need to associate the basic employee information table, the company organizational structure table and other tables to be able to query the content required by the user.

To do this, you need to use the Join statement to associate these tables. In order to improve the query efficiency of the database, it is best to create an index for the fields used for association. This can significantly speed up queries.

Recommendation 4: Seek a balance between table update speed and query speed.

As we all know, the index itself does not affect the use of the database, it is mainly to improve the query efficiency of the database. However, when the data in the database table is updated, including the addition, deletion, and modification of records, the existing indexes will be updated.

Obviously, indexes can improve query speed though. However, it will also adversely affect some table update operations. This adverse effect will be greater when more indexes are created in the table. Therefore, database administrators need to pay attention to the need for a balance between the two when setting indexes.

According to the general theory, when a certain table is mostly used for query and update, it is relatively easy to use indexes. On the contrary, when the update of a certain table record is dominant and there are relatively few queries, do not create too many indexes to avoid adverse effects on the speed of the update.

In actual work, if a table is frequently called by the view, it is better to set more indexes. When choosing a database index, you can refer to the four suggestions given above. I believe that if you master the four suggestions above, you will be able to choose a suitable index type.