Sounds like you need to split your database into two database, one for transactional data, the other for reporting. The transactional DB has almost no indexes and is simply used for CRUD. It is optimized for speed. You can setup a job to read updated data from the transactional DB and update the data in the reporting DB. The speed of updates there can be slower and additional indexes can be setup to speed reporting.

I will say that 145 indexes sounds like too many. I can't imagine a scenario where that many are needed.


>Yes, but I am talking about single update.
>
>For example, a table has 4 millions records with 145 indexes, where some of them are compound. The insert would take about 0.9 second. This is the part I would be interested to know if optimization can be done.