From Database Developer to New DBA: Boosting MySQL Efficiency and Automation

Database Development Experience

The author began as an intern on the DM6 product (达梦) in 2009, reading source code and learning the internals of syntax analysis (yacc.yy), REDO/UNDO logging, and the execution engine. In 2010 the team started DM7, a ground‑up rewrite. Contributions included:

Table creation and B‑tree split/merge logic.

Job scheduling module.

Oracle‑compatible packages and PL/SQL support, including a PL/SQL debugger ( dmgdb) whose command set mirrors GNU gdb.

Implementation of a column‑store engine (two versions) and Oracle synonym handling.

These tasks deepened understanding of execution stacks, instruction generation, and the “bypass intervention” technique, a precursor to modern MySQL plugin architectures.

Transition to MySQL Operations

In 2013 the author joined Qunar.com as a MySQL DBA. Unlike development, DBA work focuses on keeping live MySQL instances highly available, responding quickly to incidents, and delivering value‑added services to business users.

Efficiency Improvement Practices

Identify and solve own pain points – bridging the gap between requirement and implementation accelerates delivery and personal growth.

Systematic data collection – maintain structured records of instances, configurations, and incidents to avoid reliance on memory and enable accurate tracking.

Automation platform – with reliable data, automate repetitive tasks (e.g., provisioning, health checks) to improve speed, accuracy, and consistency.

Leverage all resources – use machines, colleagues, knowledge bases, and leadership to proactively solve problems and avoid bottlenecks.

New DBA Model

The “New DBA” emphasizes proactive, data‑driven operations:

Intelligent Alerting – low‑threshold alerts filter noise, route critical events instantly, and batch low‑priority alerts for periodic handling.

Full‑Log Analysis – packet‑capture based logging captures >95% of MySQL traffic (target 100%). This provides a trustworthy audit trail for:

Resource usage accounting (e.g., zombie accounts).

Precise query timing and frequency for troubleshooting.

Correlation with slow‑query logs.

Security auditing.

Application‑database stack tracing.

Slow‑Query Risk Index – quantifies impact using execution time, rows scanned, and frequency. Queries are ranked by risk score, enabling targeted remediation and measurable reduction of P95/P99 latency. Reference implementation details can be found in the author’s “MySQL慢查询风险指数模型设计” article (URL: http://mp.weixin.qq.com/s?__biz=MzA3NDcyMTQyNQ==∣=2649268174&idx=1&sn=dcf249d11aaf2ae5a227fdb223f1c9a0).

High‑Availability (HA) Verification – before containerizing databases, assess uptime (nines), failover time, and data‑loss risk. Verify that switch‑over does not impact business and that VIP or monitoring mechanisms are reliable.

Automation of Operations – decompose manual procedures into atomic tasks, orchestrate them with a workflow engine, and execute zero‑downtime migrations. Example: converting 100 MySQL‑3M clusters to Percona XtraDB Cluster (PXC) in two months with no service interruption.

Additional tools developed in this workflow include:

Inception – an open‑source SQL review and execution‑plan verification tool (GitHub: https://github.com/mysql-inception/inception).

MySQL sniffing program – a packet‑capture based data collector (details in “谁动了我的数据？去哪儿网MySQL嗅探程序” article, URL: http://mp.weixin.qq.com/s?__biz=MzA3NDcyMTQyNQ==∣=2649268428&idx=1&sn=98812048b33af2678f9d1ea16f6a785f).

Outcome

By adopting these practices, DBAs shift from reactive fire‑fighting to proactive engineering, achieving higher efficiency, broader coverage, greater autonomy, and improved job satisfaction.