I realized that Microsoft SQL server is easy to use and setup. It’s UI (management studio) is easy to use, user friendly and nice. However, used by beginner developer, usually the SQL Server will perform bad. As a beginner at MS SQL Server world, what do you need to know?
In this series, I will provides hints and small description about what topics you need to learn beforehand. If you need detailed explanation, you need to do detailed research yourself.
Database transaction isolation level and lock hints
This is the very first thing that you need to know when developing system with SQL Server as database. Why? Because not knowing this will grant you over 80% possibility of deadlock when used in high-transaction system.
By default, MS SQL Server use Serializable isolation level for read queries (select). It is the heaviest-locking isolation level that you can achieve with SQL Server. The most secure, but also the most problematic. It basically locks the table (or page) every time you do select/insert/update/delete queries. In heavy read and light write applications such as stackoverflow, this usually cause problems.
Microsoft recommend Read Committed Snapshot Isolation (RCSI) level for common system. But still you need to search for yourself the best isolation level that is most suit with your apps.
By default, MS SQL enables the auto commit feature, means that every insert/update/delete that is not inside a transaction will be wrapped in a transaction and committed. This is bad for performance, because every commit will add record into your database log and it hurts performance. This is especially happen in looped-generated statement (to insert/update/delete many rows from applications).
Basically to avoid this, you need to wrap your statements in a transactions, or set auto commit off.
Backup Recovery Model
By default, MS SQL has backup recovery model set to FULL. In contrast to SIMPLE recovery model, full recovery model enables you to point-in-time recovery per transaction committed. While in simple model it is not supported. In short, set to simple model if you don’t think that point-in-time recovery is required, especially in logging database.
Indexing is complex, but in case you need to maintain database performance against big volume data, you need to learn indexing. First, you need to know how to get the query execution plan. Next, you need to know the index seek vs index scan, key lookup, and sargable query.
In short, what I recommend is:
* Always use primary keys in all your tables,
* If you need to do join query, ordered by recommendation, it’s better if you can:
1) join between primary key/foreign key
2) the joining field contains same data type and length
3) avoid computational at where clause or joining fields, eg: isnull, where fieldA < fieldB + 1
4) do not use leading wildcard (percent) in string search
Opening connection and user authentication is providing some performance impact. It is not much, but exists, especially when the application server is far away from database server. Please note that stating there is connection overhead does not means that keeping the connection open is the solution. What you need to avoid is opening/closing connection inside an application loop. It’s better to re-factor it to become more like set-based operation.
Scalar vs table-valued function
In MS SQL, there are 3 types of functions, that is scalar function, table valued function and multi-statement table-valued function. Execution plan wise, scalar and multi-statement table valued is same, while table-valued function is operated more like accessing view. So let’s consider multi-statement table valued function the same as scalar in this topic.
Scalar function inside select column / join / where clause will be converted in looping operations. Meanwhile table-valued function will be treated the same as view, and then being included in query plan as set operations. So, in short, if the function you defined is accessing any table, avoid define it in scalar function.
SQL Server, after being installed can be easily used. But not knowing the features of SQL Server and then using it to make complex system can cause problems. Before actually using it in real system, I suggest that you at least know the points I described above.
However, even if I know those points, it does not immediately makes me know all the SQL Server and the best configurations for each scenarios. I am not a database administrator after all.