Tips for optimizing SQL Server indexes_PHP tutorial

There are several tools in SQL Server that allow you to detect, tune, and optimize SQL Server performance. In this article, I will explain how to use SQL Server tools to optimize the use of database indexes. This article also involves general knowledge about indexes.
Common sense about indexes

The biggest factor affecting database performance is the index. Because of the complexity of the issue, I can only briefly touch on it, but there are several good books on this subject that you can read. I will only discuss two types of SQL Server indexes here, namely clustered indexes and nonclustered indexes. When considering what type of index to create, you should consider the data type and the column that holds the data. Likewise, you must also consider the types of queries your database is likely to use and which types of queries are used most frequently.
Type of index
If the column stores highly related data and is often accessed sequentially, it is best to use a clustered index. This is because if you use a clustered index, SQL Server will physically sort it in ascending order (default) Or rearrange the data columns in descending order so that you can quickly find the queried data. Similarly, when the search is controlled within a certain range, it is best to use clustered indexes for these columns. This is because due to the physical rearrangement of the data, there is only one clustered index on each table.
Contrary to the above situation, if the columns contain less relevant data, you can use nonculstered indexes. You can use up to 249 nonclustered indexes on a table - although I can't imagine a practical application using that many indexes.
When a table uses primary keys, by default SQL Server will automatically create a unique cluster index for the column(s) containing the key. Obviously, establishing unique indexes on these column(s) means the uniqueness of the primary key. When establishing a foreign key relationship, it is a good idea to create a nonclustered index on the foreign key cloumn if you plan to use it frequently. If the table has a clustered index, then it uses a linked list to maintain the relationship between data pages. Conversely, if the table does not have a clustered index, SQL Server will save the data pages in a stack.
Data page
When the index is established, SQL Server creates a data page (datapage), which is a pointer used to speed up search. When an index is created, its corresponding fill factor is set. The fill factor is set to indicate the percentage of data pages in the index. Over time, database updates consume existing free space, which causes pages to be split. The consequence of page splits is that the performance of the index is reduced, and therefore queries using the index result in fragmented data storage. When an index is created, the index's fill factor is set, so the fill factor cannot be dynamically maintained.
In order to update the fill factor in the data page, we can stop the old index, rebuild the index, and reset the fill factor (note: this will affect the operation of the current database, please use it with caution on important occasions). DBCC INDEXDEFRAG and DBCC DBREINDEX are two commands that clear clustered and nonculstered index fragments. INDEXDEFRAG is an online operation (that is, it does not block other table operations, such as queries), while DBREINDEX physically rebuilds the index. In most cases, rebuilding the index can better eliminate fragmentation, but this advantage comes at the expense of blocking other actions currently occurring on the table where the index is located. When a large fragmented index occurs, INDEXDEFRAG will take a longer time because the command runs based on small transactional blocks.