The process of tuning database performance after one SQL statement (300 million)

Changing the vast majority of SQL queries to stored procedures can undoubtedly improve some performance.
All operations that use "select * from xxx" are specific to the required fields.
Join is used to connect more than two tables with a large amount of data, and views are used for queries with little changes to the basic data table, and indexes are created for the view. The reason is from the SQL Server online help manual: "For standard views, it is costly to dynamically generate a result set for queries in each referenced view, especially for those views that involve complex processing of a large number of rows (such as aggregating a large amount of data or joining many rows. If such views are frequently referenced in queries, you can create a unique clustered index for the view to improve performance. After creating a unique clustered index for a view, the result set is stored in the database, just like a table with a clustered index.
Another benefit to creating an index for a view is that the optimizer can use the index of a view in a query that is not directly specified in the FROM clause. In this way, you can retrieve data from the index view without re-encoding. The resulting efficiency also benefits existing queries ."
All queries that use "select count (*) from xxx" or "select count (id) from xxx" (where id is the primary key) are changed to "select count (1) from xxx ", theoretically using * for aggregation, SQL Server will automatically find the most suitable field for aggregation, but this will still occupy the system overhead, even if the primary key is not 1 faster.
For a combined query with multiple conditions, we generally write a stored procedure condition in the form of "where (@ condition is null) or (condition = @ condition)" to query, however, this operation causes performance problems due to "is null". After repeated on-site detection, "where 1 = 1" is used ", then, according to the condition "IF @ Condition is not null set @ sqlText = @ sqlText + 'AND Condition = ''' + @ condition + '''', finally, the "exec sp_executesql @ sqlText" method can indeed bring significant performance improvement. The analysis should be "is null" or "is not null", leading to index failure, A full table scan is performed.
To create an appropriate index for a table using the row_number () function, you must have the most appropriate index to avoid performance problems caused by the Full-Table row_number () operation during index reconstruction, in addition, the direction of the index is also very important. For example, time-based indexes use descending order, which is usually higher than ascending order.
This is not a performance issue, but it is also important. In the stored procedure, use the scope_identity () function to obtain the latest scalar, instead of the global variable @ Identity, because @ Identity is affected by the trigger and the correct value is lost.