Years ago, I stumbled into a very similar (legacy...) “kitchen-sink experience”and the basic problem turned out to be that all of the settings were being stored in one XML record/file. The application would absolutely grind to a dead-stop. But the actual solution turned out to be fairly simple: carve off three of the top-level sections of the file (thus dividing the total into 200-odd subsections), and store each piece as an XML-formatted BLOB field keyed by a set of fields consisting of three top-level keys.
Intuitively, I feel that the best overall solution to a problem like this one is to store the data in a BLOB (that is, a VARCHAR field of arbitrary size) in a “well-known format” ... JSON if you know you’re among friends, otherwise XML. This compromise allows you to let the database handle storage, of all or a subset of the data, without condemning you to a hell of impossible-to-maintain code that tries to “wedge” arbitrary data into a rows-and-columns pure SQL format. This is an extremely well-known and widely-used approach.