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

2. Sponsors
Gold
Silver
Geek

3. Eduardo Pivaral SQL Server Database Administrator/Developer
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

4. 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

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

6. 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.

7. 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:

8. Proper Database Design
Fixing issues before they exists

9. 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

10. 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.

11. 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:

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

13. 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.

14. 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

15. 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:

16. 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

17. 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 *

18. 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?

19. 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:

20. 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:

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

22. 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

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