High-concurrency SQL Server Access Solution

Problem: the background system needs to connect to SQL Server, and the instantaneous data operations may be very large, as if tens of thousands of data needs to be inserted into the database, however, when data is inserted, other threads may need to access the database. The priority of data insertion operations is relatively low, and other accesses require immediate return. After a long time, I don't know how to solve this problem, hope you can enlighten me. Answer: 1. improve server hardware configuration 2. use replication and other synchronization technologies to synchronize frequently-operated tables into multiple copies and distribute operations to these synchronized tables. for data queries, try to use the read uncommitted transaction isolation level to reduce the lock overhead ====you can use Snapshot isolation level ==-- when querying, use SET transaction isolation level read uncommitted -- or with (nolock) -- and create an index, minimize time-consuming queries-multiple servers share the pressure-improve hardware performance this is the most cost-consuming but most effective method === select * from TB (nolock) is not locked during Query) use an image copy to add read-only databases! === In addition to the above methods, 2005 can also adopt the row-versiong based snapshot transaction isolation level. Create a snapshot database to isolate queries and updates.