None of the *_client_id columns carried an index, so agent/includes/inc_all_client.php was doing a full table scan per badge count before the page rendered a byte - 27 of them. The main agent context runs 8 counts and the admin context none, which is why the client side nav was the only one that felt slow.
24 indexes, shaped (<entity>_client_id, <entity>_archived_at) where the query pairs the two and the client column alone otherwise. The archived column is always trailing and never an index of its own - on a healthy instance nearly every row has it NULL, so it cannot lead. recurring_tickets, services, invoices, recurring_invoices and calendar_events get a single column because their queries carry no archived filter; invoices is in that group because the money total there spans archived rows on purpose. payments.payment_invoice_id and transfers.transfer_revenue_id are join keys rather than client scoping but sit on the same page's critical path.
Migration checks information_schema.STATISTICS before each ALTER, since MySQL has no ADD INDEX IF NOT EXISTS and re-adding is an error - safe to re-run and safe where an index was added by hand. db.sql carries the same keys so fresh installs skip the update step.
Wider than the side nav: these are the columns clientScopeSql() filters on, so every client-scoped list page was paying for their absence. Expect the ALTERs to be the slow part of the upgrade on a mature instance.
