Unique indexes
Unique indexes do not allow two rows to have the same index value.
Most databases do not allow a newly created unique index to be saved with a table if there are duplicate key values in existing data. The database also refuses to accept this data when new data will duplicate key values in the table. For example, if a unique index is created on the ID card column in the user table, all ID cards cannot be duplicated
Primary Key Index
Primary key index is a special type of unique index.
Database tables usually have a column or combination of columns whose values are used to uniquely identify each row in the table. This column is called the primary key of the table.
Defining a primary key for a table in the database diagram will automatically create a primary key index, which is a special type of unique index. Primary key indexes require that each value in the primary key be unique. It also allows fast access to data when primary key indexes are used in queries.
Comparison:
1. For the primary key/unique constraint, oracle/sql server/mysql, etc. will automatically create a unique index;
2. The primary key does not necessarily contain only one field, so it is necessary if you build a unique index on one of the fields of the primary key;
3 . The key can be used as a foreign key, but the unique index cannot;
4. The main key cannot be empty, and the unique index can be used; 5. The main key
can also be a combination of multiple fields ; (2). Each table can only have one.
Notes on indexing
1. For sub-tables of combination or reference relationship (when the amount of data is large), a non-clustered index needs to be established on the columns of the associated main table (such as the product ID field in the order details table, the association in the order details table) the order ID field)
2. The size of the index key cannot exceed 900 bytes. When the size of the list exceeds 900 bytes or the sum of several columns exceeds 900 bytes, the database will report an error.
3. If a large number of indexes are built in the table, it will affect the performance of INSERT, UPDATE and DELETE statements, because when the data in the table is changed, all indexes will have to be adjusted appropriately. Too many indexes on frequently updated tables need to be avoided, and indexes should be kept narrow, that is: with as few columns as possible.
4. Create indexes for predicates that are often used in queries, such as code, name, etc., which are used to quickly find drop-down references. The like conditional statement in the query sql statement of the existing drop-down reference on the platform should be changed to without the preceding wildcard. It is also necessary to pay attention to the index design of the Order By and Group By predicates. The predicates of the Order By and Group By need to be sorted. In some cases, indexing the predicates of the Order By and Group By will avoid the sorting action during query.
4. For columns whose content is basically repeated, such as only 1 and 0, it is forbidden to build an index, because the index has extremely poor selectivity, which will mislead the optimizer to make wrong choices under certain circumstances, resulting in a great decrease in query speed.
5. When an index consists of multiple columns, it should be noted that the column with strong selectivity should be placed in the front. Only the difference in the order before and after, there may be an order of magnitude difference in performance.
6. Indexing small tables may not produce optimization effects, because the query optimizer may take longer to traverse the index used to search data than to perform a simple table scan, and the size of the table needs to be considered when designing the index. Tables with no more than 100 records should not be indexed. Indexing is not recommended for small tables that are frequently operated (the number of records should not exceed 5000)