A client in a session can lock a certain table they are working on, in order to prevent other clients from using the same table. This process will avoid any data losses that might occur when multiple users work on the same table simultaneously. A client can lock a table and unlock it whenever needed. However, if a table is already locked by a client session, it cannot be accessed by other client sessions until it is released.
READ LOCK − If you apply this lock on a table the write operations on it are restricted. i.e., only the sessions that holds the lock can write into this table.
WRITE LOCK − This lock allows restricts the sessions (that does not possess the lock) from performing the read and write operations on a table.
You need to run a bulk UPDATE that touches 50k rows in a MyISAM table while preventing any reads or writes during the operation. Walk me through the exact statements you'd run and what happens if the connection drops halfway through.
A teammate says 'just add LOCK TABLES before every query to be safe.' What's wrong with that approach, and what would you see in SHOW PROCESSLIST if they did it on a busy InnoDB table?
Our nightly analytics job does LOCK TABLES events WRITE, then runs a 10-minute INSERT ... SELECT. The checkout service starts timing out with 'Lock wait timeout exceeded.' You can't change the analytics query. What are two ways to mitigate this without rewriting the job?
A developer used LOCK TABLES orders WRITE, order_items WRITE in a stored procedure but forgot UNLOCK TABLES. The app pool exhausted connections. How do you diagnose this from the MySQL side, and what configuration would limit the blast radius next time?
We're migrating a 2TB MyISAM table to InnoDB with zero downtime. The table has heavy read/write traffic. Outline a strategy that avoids long table locks during the final cutover, including how you'd handle the brief moment when both engines must stay in sync.
A high-throughput service uses SELECT ... FOR UPDATE SKIP LOCKED for a work queue. Under load, you see 'Lock wait timeout' spikes despite low CPU. Explain the likely contention pattern and how you'd redesign the locking granularity or isolation level to fix it.
Two teams own services that share a MySQL cluster. Team A wants to run a 4-hour ALTER TABLE on a core table; Team B can't tolerate more than 30s of write unavailability. Design a cross-team coordination plan and technical approach (tools, replication topology, rollback) that satisfies both, and explain how you'd get organizational buy-in.
You're inheriting a legacy system where 40% of queries use explicit LOCK TABLES on InnoDB tables. The new architecture requires horizontal sharding. How do you phase out table locks without a big-bang rewrite, and what observability would you add to prove safety at each step?