The advantages and disadvantages of using indexes (Oracle test)

The benefits of creating an index 

-Help users improve query speed 

-Use the uniqueness of the index to control the uniqueness of the record 

-Can accelerate the connection between the table and the table 

-Reduce the time of grouping and sorting in the query 

Disadvantages of creating an index

-Storage index occupies disk space

-Perform data modification operations (INSERT, UPDATE, DELETE) to generate index maintenance

----------------------------------------------------------------------------------------------

Indexing is the most effective method to improve data query, and it is also the most difficult technology to fully grasp, because the correct index may increase the efficiency by 10,000 times, and the invalid index may waste database space and even greatly reduce the query performance.

  Index management cost

  1. Disk space for storing indexes

  2. Perform index maintenance generated by data modification operations (INSERT, UPDATE, DELETE)

  3. Additional fallback space is required during data processing.

  Actual data modification test:

  A table has fields A, B, C, and inserts 10,000 rows of records at the same time.

  The average completion time when no index is built is 2.9 seconds

  The average completion time after indexing the A field is 6.7 seconds

  The average completion time after indexing the A and B fields is 10.3 seconds

  The average completion time after indexing the A field, B field and C field is 11.7 seconds

  From the above test results, it is obvious that the index has an impact on data modification

  Indexes are classified by storage method

  B*tree index

  The B*tree index is the most commonly used index. Its storage structure is similar to the index structure of a book. There are two types of storage data blocks: branch and leaf. The branch block is equivalent to the large catalog of the book, and the leaf block is equivalent to the specific book page indexed. . Both general index and unique constraint index use B* tree index.

  Bitmap index

  Bitmap index storage is mainly used to save space and reduce ORACLE's access to data blocks. It uses bitmap offset to correspond to the row ID number of the table. Bitmap index is generally used for table fields with too many repeated values. Bitmap indexes are rarely used in actual intensive OLTP (data transaction processing), because OLTP will perform a large number of delete, modify, and create operations on the table. ORACLE will lock the data block to be operated every time it performs an operation, so Multi-person operations are prone to wait for data block locks or even deadlock. There are advantages in applying bitmaps in OLAP (data analysis and processing), because most of OLAP is query operations on the database, and generally use data warehouse technology, so a large amount of data using bitmap index to save space is obvious.

  Index by function

  Unique index

  The unique index has two functions, one is the data constraint, the other is the data index. The data constraint is mainly used to ensure the integrity of the data. Each record in the index record generated by the unique index corresponds to a unique ROWID.

  Primary key index

  The index generated by the primary key index is the same as the unique index, except that it is automatically created by the system when the database creates the primary key.

  General index

  The general index does not produce data constraint effect, and its function is mainly to create an index table for fields to improve the speed of data query.

  Indexes are classified by index objects

  Single column index (index of a single field of the table)

  Multi-column index (index of multiple fields in the table)

  Functional index (index for performing functional operations on fields)

  How to build a functional index:

  create index charge date index on GC_DFSS(trunc(sk_rq))

  create index complete customer number index on yhzl(qc_bh||kh_bh)

  After the function is indexed, if the current session is to be referenced, the query_rewrite_enabled of the current session should be set to TRUE.

  alter session set query_rewrite_enabled=true

  Note: If the user function is indexed, the user function should be added with a deterministic parameter, which means that the function returns a fixed value when the input value is fixed. example:

  create or replace function trunc_add(input_date date)return date deterministic

  as

  begin

  return trunc(input_date+1);

  end trunc_add;

  Application index scan classification

  INDEX UNIQUE SCAN (scan by index unique value)

  select * from zl_yhjbqk where hbs_bh='5420016000'

  INDEX RANGE SCAN (scan by index value range)

  select * from zl_yhjbqk where hbs_bh>'5420016000'

  select * from zl_yhjbqk where qc_bh>'7001'

  INDEX FAST FULL SCAN (scan all quickly by index value)

  select hbs_bh from zl_yhjbqk order by hbs_bh

  select count(*) from zl_yhjbqk

  select qc_bh from zl_yhjbqk group by qc_bh

  Under what circumstances should index

  Primary key of the table

  Automatically create a unique index

  Such as hbs_bh (user identification number) in zl_yhjbqk (basic user situation)

  Unique constraint of table column

  ORACLE uses indexes to ensure data integrity

  Such as lc_bh+hj_sx (process number + link sequence) in lc_hj (process link)

  Fields for Direct Conditional Queries

  Fields used for conditional constraints in SQL

  Such as qc_bh (zone book number) in zl_yhjbqk (basic user situation)

  select * from zl_yhjbqk where qc_bh=’7001’

  Fields associated with other tables in the query

  Fields often establish foreign key relationships

  Such as jldb_bh (metering point table number) in zl_ydcf (electricity component)

  select * from zl_ydcf a,zl_yhdb b where a.jldb_bh=b.jldb_bh and b.jldb_bh=’540100214511’

  The sorted field in the query

  If the sorted field is accessed through the index, it will greatly improve the sorting speed

  select * from zl_yhjbqk order by qc_bh (build qc_bh index)

  select * from zl_yhjbqk where qc_bh='7001' order by cb_sx (build qc_bh+cb_sx index, note: just an index, which includes qc_bh and cb_sx fields)

  Fields of statistics or grouping statistics in the query

  select max(hbs_bh) from zl_yhjbqk

  select qc_bh,count(*) from zl_yhjbqk group by qc_bh

  Under what circumstances should not build or build less index

  Too few table records

  If a table has only 5 records and an index is used to access the records, then the index table must be accessed first, and then the data table is accessed through the index table. Generally, the index table and the data table are not in the same data block. In this case, ORACLE must at least round-trip Read the data block twice. Without indexing, ORACLE will read all the data at once, and the processing speed will obviously be faster than using the index.

  For example, the table zl_sybm (using department) generally has only a few records, and indexing any field except the primary key will not produce performance optimization. In fact, if you perform statistical analysis on this table, ORACLE will not use it. Index, but automatically perform full table access. Such as:

  select * from zl_sybm where sydw_bh='5401' (indexing sydw_bh will not produce performance optimization)

  Tables that are frequently inserted, deleted, and modified

  For some frequently processed business tables, the index should be reduced as much as possible when the query allows, such as zl_yhbm, gc_dfss, gc_dfys, gc_fpdy and other business tables.

  Table fields with repeated and evenly distributed data

  If a table has 100,000 rows of records, a field A has only two values ​​of T and F, and the distribution probability of each value is about 50%, then indexing the field of this table A will generally not increase the query speed of the database .

  Table fields that are often queried together with the main field but the main field index value is relatively large

  For example, the gc_dfss (Electricity Charges Collected) form often queries the status of a certain payment according to the charging serial number, household identification number, meter reading date, electricity bill occurrence year and month, and operation flag. If all fields are built in an index That will increase the time for data modification, insertion, and deletion. In fact, analyzing a collection of payments will reduce the records to only a few records if it is indexed by the charge sequence number. If you query by the following fields, the performance will not be affected. Have too much impact.

  How to return results only by index

  An index generally includes single or multiple fields. If you can directly apply the index without accessing the table and return the results, it will greatly improve the performance of the database query. Compare the following three SQLs, which indexed the hbs_bh and qc_bh fields of the table zl_yhjbqk:

  1 select hbs_bh,qc_bh,xh_bz from zl_yhjbqk where qc_bh=’7001’

  Execution path:

  SELECT STATEMENT, GOAL = CHOOSE 11 265 5565

  TABLE ACCESS BY INDEX ROWID DLYX ZL_YHJBQK 11 265 5565

  INDEX RANGE SCAN DLYX Zone Book Index 1 265

  Average execution time (0.078 seconds)

  2 select hbs_bh,qc_bh from zl_yhjbqk where qc_bh=’7001’

  Execution path:

  SELECT STATEMENT, GOAL = CHOOSE 11 265 3710

  TABLE ACCESS BY INDEX ROWID DLYX ZL_YHJBQK 11 265 3710

  INDEX RANGE SCAN DLYX Zone Book Index 1 265

  Average execution time (0.078 seconds)

  3 select qc_bh from zl_yhjbqk where qc_bh=’7001’

  Execution path:

  SELECT STATEMENT, GOAL = CHOOSE 1 265 1060

  INDEX RANGE SCAN DLYX Zone Book Index 1 265 1060

  Average execution time (0.062 seconds)

  It can be seen from the execution results that the third SQL is the most efficient. It can be seen from the execution path that the first and second SQLs have performed the step of TABLE ACCESS BY INDEX ROWID (accessing the table through ROWID), because the returned result column includes the currently used index (qc_bh) unindexed column (hbs_bh, xh_bz), and the third SQL returns the result directly through QC_BH, which is the method of returning the result directly through the index.

  How to rebuild the index

  alter index table power result table primary key rebuild

  How to quickly create an index for a large data volume table

  If the records of a table reach more than 1 million, it may take a long time to index one of the fields, and even cause the server database to crash, because ORACLE needs to take out all the contents of the index field and perform comprehensive Sorting, if the amount of data is large, it may cause the server to run out of memory for sorting and refer to disk swap space, which will seriously affect the work of the server database. The solution is to increase the sorting memory parameter in the database startup initialization. If you want to make a large number of index modifications, you can set the sorting memory above 10M (the default size of ORACLE is 64K). After the index is built, the parameters should be modified back, because Such a large sorting memory is generally not used in actual OLTP database applications.

Guess you like

Origin blog.csdn.net/feng8403000/article/details/114856999
Recommended