T-SQL Basics: Coding for performance Eduardo Pivaral (MCSE, MCSA) – Feb 2019

Sponsors Gold Silver Geek

Eduardo Pivaral SQL Server Database Administrator/Developer www.sqlguatemala.com Regular technical author for different sources an developer/reviewer of Open Source tools for SQL Server database administration, development and productivity. Board member of PASS Guatemala SQL Server users group. Microsoft Certified Solutions Expert: Data Management and Analytics Microsoft Certified Solutions Associate: SQL 2016 Database Administration Microsoft Certified Solutions Associate: SQL Server 2012/2014 Microsoft Certified Professional MSSQLTips.com Rookie of the year 2018 Eduardo Pivaral @EduardoDBA Epivaral

Agenda Database programming mindset: Code for the future, not for the past Proper database design: Datatype selection, N-tier programming Indexes and statistics: Improve performance, but as alcohol, without abuse! Execution plans: Your first (and almost only) debugging tool DEMO: T-SQL tips and examples to improve performance

Database programming mindset: Code for the future, not for the past

Long Development life cycles can lead to releases on old systems Choose agile methodologies when possible Use databases for different modules Investigate new features that could improve existing code Design your application to support: High volumes of data and concurrency Implement data purging/historical movement processes Databases can grow uncontrollably due to message logs and historical data.

Implement reusable, scalable code On development and test machines, apply latest service packs/patches available on all your development software. Implement reusable, scalable code Comment and format your code: You won’t recognize your own code from time ago. Test your code trying to make it fail. Having issues? ask for help! Community is always willing to lend you a hand. Further reading: https://www.sqlguatemala.com/2018/02/considerations-for-dealing-with-big.html

Proper Database Design Fixing issues before they exists

N-Tier Programming Encapsulate Data operations on database tier It improves performance and security Code changes are transparent to application and presentation tier Minimize Locks by reducing network and IO usage Migrations are easier without database code on upper tiers

Avoid using SELECT * to send data to client application By explicitly defining columns, network and disk IO is reduced Security is improved by sending only required records ASYNC_NETWORK_IO wait can be avoided Filter data on the database tier Data sent to client is reduced even more SARGABLE: search +‎ argument +‎ -able Sort data on presentation tier Sorting is a resource-intensive operation, can negatively impact performance.

Proper Datatype Selection With millions of records, correct datatype make a lot of difference on performance and storage utilization Wrong datatypes will require data conversions (additional overhead) Filtering/Joining different datatypes will require implicit conversions (sub- optimal queries) Comparison between storage used for distinct datatypes storing the exact same data: Further reading: https://www.sqlguatemala.com/2018/07/saving-disk-space-by-choosing-correct.html

Indexes and Statistics Powerful allies if used correctly* *…but what is correct?

Indexes are special structures associated to tables or views that store information on a B-tree for quick data retrieval Clustered index: Stores the table ordered by a specific column (normally the primary key). There can be just one. Have faster performance on numeric, sequential values. Non-clustered index: A separate structure that stores the pointer to a row location on the original object, by a specific column. Performance depends on size, number of columns and datatypes. Heap: Table without clustered index. Only allows full table scans to locate records.

A good index is when values have a high selectivity (or cardinality) They improve query performance, but require additional disk storage and IO. Limit your index creation. A good index is when values have a high selectivity (or cardinality) High Selectivity Low Selectivity

A Covering index is when index is capable of provide all the data by itself, without accessing pointer to original object. Can be achieved by using indexed columns or by included columns. Included columns are not indexed, just are part of the index data Require extra storage, so use with caution Further reading: https://www.sqlguatemala.com/2018/02/performance-basics-key-lookup-operator.html

Statistics are used by Query Optimizer to create execution plans based on distribution of required values. Outdated or non-existent statistics can lead to poor performing queries, even with proper indexes created. Density is the number of duplicated values a column can have, is used to calculate selectivity and enhance cardinality estimates. High density variations on a given column can lead to parameter sniffing issues. Data with potential parameter sniffing issues

Updating statistics will cause related queries to recompile. With AUTO_CREATE_STATISTICS enabled, statistics are created by the query optimizer as necessary, with _WA prefix. Statistics automatically created, are strictly created on single columns. With AUTO_UPDATE_STATISTICS enabled, statistics are updated automatically by the engine when column changes reach a threshold*. Be aware that this threshold could not work for you. Updating statistics will cause related queries to recompile. Use DBCC SHOW_STATISTICS to show statistics information * https://docs.microsoft.com/en-us/sql/relational-databases/statistics/statistics?view=sql-server-2017#autoupdatestatistics-option

Your first (and almost only) debugging tool Execution Plans Your first (and almost only) debugging tool It seems you are trying to debug a query, do you need assistance?

Execution plans are the results of SQL declarative language It is a calculation of most efficient way to execute a query. Since this is an attempt, optimal way is not always the chosen one. If a query is slow, execution plan should be the first thing to check. Even when SSMS provides a built-in debugging feature, it is only useful for some cases. For example stored procedures, or queries with many lines of code. Further reading: https://www.sqlguatemala.com/2018/09/different-methods-to-generate-query.html https://sqlserverfast.com/epr/

Estimated vs Actual Execution Plan Estimated Plan is how a query will be executed based on existing indexes, statistics and server load at request moment. Actual plan include run time statistics (number of rows processed) to the execution plan information. For most cases, Estimated and Actual plan will be the same. Further reading: https://sqlserverfast.com/epr/common-properties/

T-SQL tips to improve performance Demos T-SQL tips to improve performance

Demos Compatibility level: be aware of deprecated features Filtering basics: SARGABLE arguments Table Scan vs Index Scan vs Index Seek Covering indexes Indexed views Implicit conversions Parameter Sniffing Memory Grants Joining records with NULL Database Collation: considerations when working with multiple databases DMOs to find top resource intensive queries

Want to know more? Having doubts about this presentation? Thank you! Want to know more? Having doubts about this presentation? Visit me at: www.SQLGuatemala.com Eduardo Pivaral @EduardoDBA Epivaral