I run a set of self-developed applications on a typical shared hosting service offering. I moved from a static configured table list of allowed tables to one based on a list of tables bases on a prefix from the D/B metadata. When I did promote this version to the public service, my per-request latency increased by an average 2.3–2.4 secs. Some instrumentation revealed that this was entirely down to one SQL query:
SELECT TABLE_NAME AS name
FROM information_schema.tables
WHERE TABLE_SCHEMA = '<DBname>'
AND TABLE_NAME LIKE '<TablePrefix>%';
I used this because I wanted to explicitly name the column in the result set. However, coding around this with an alternate query adds an extra line of code which ran in <2 mSec:
SHOW TABLES LIKE '<TablePrefix>%';
My service provider uses Enterprise MySql 5.0.92-50 so I can't do any profiling. This is a scaling issue as it doesn't occur on my dev environment and test VM where I can profile. They support thousands of users so the live schema will be extremely large, but even so connection and most queries only take milliseconds.
Does anyone know why querying the memory-based information_schema on a large multi-user system would take so long?
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…