After more than two decades of diagnosing slow MySQL workloads across high-traffic SaaS platforms, payment gateways, and analytics backends, we have learned one durable truth: almost every painful performance incident traces back to a query the optimizer chose to execute differently than the engineer expected. The application looks correct. The index appears to exist. Yet response times balloon under load, replicas fall behind, and the on-call engineer is left staring at a process list full of queries stuck in Sending data.

The execution plan is where intent meets reality. It is the single most important diagnostic artifact in MySQL performance engineering, and reading it fluently is a non-negotiable skill for anyone responsible for production database reliability. In this guide we will walk through how the MySQL optimizer thinks, how to read every meaningful column of an EXPLAIN output, and the concrete tuning patterns our team at MinervaDB applies when we turn a multi-second query into one that completes in single-digit milliseconds.

What a MySQL Execution Plan Actually Represents

When you submit a SQL statement, MySQL does not simply execute it top to bottom. The cost-based optimizer evaluates the many possible ways the query could be satisfied — which index to use, which table to read first in a join, whether to sort in memory or on disk — and selects the plan it estimates to be cheapest. That estimate is built from table statistics, index cardinality, and a set of internal cost constants.

The crucial word here is estimate. The optimizer is frequently right, but it works from statistics that may be stale, from cardinality samples that may be misleading, and from assumptions about data distribution that rarely hold for real-world skewed datasets. The execution plan exposes the decision the optimizer made so that you can evaluate whether that decision was sound. If you want to understand the underlying machinery in depth, the MySQL optimization documentation is the authoritative reference.

The EXPLAIN Statement and Its Output Formats

You generate an execution plan by prefixing any SELECT, INSERT, UPDATE, DELETE, or REPLACE with the EXPLAIN keyword. MySQL 8.0 offers four distinct output formats, and choosing the right one changes how quickly you reach a diagnosis.

-- Traditional tabular output
EXPLAIN SELECT * FROM orders WHERE customer_id = 4471;

-- Detailed JSON with cost estimates
EXPLAIN FORMAT=JSON SELECT * FROM orders WHERE customer_id = 4471;

-- Readable tree of the iterator pipeline (8.0.16+)
EXPLAIN FORMAT=TREE SELECT * FROM orders WHERE customer_id = 4471;

-- Actual execution with real timings (8.0.18+)
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 4471;

The traditional format is the fastest to scan for a quick sanity check. FORMAT=JSON is what we reach for when we need the optimizer’s actual cost numbers and the precise filtering percentages. FORMAT=TREE presents the plan as the pipeline of iterators MySQL will execute, which maps far more intuitively to how the engine actually processes rows. And EXPLAIN ANALYZE — which we will return to later — is the difference between theory and proof. For the complete column reference, the official EXPLAIN output documentation is indispensable.

Reading the Traditional EXPLAIN Columns

The tabular output packs an enormous amount of signal into a handful of columns. Here is how we read each one, in the order that matters most for diagnosis.

type — the access method

If we could see only one column, it would be this one. The type column tells you how MySQL accesses rows in each table, and it is the strongest single predictor of query health. Ranked from best to worst, the values you will encounter most often are:

• const / system — at most one matching row, read once and treated as a constant. This is what you get when you look up a row by primary key with a literal value. It is as fast as MySQL gets.
• eq_ref — exactly one row is read from this table for each row combination from preceding tables, typically on a join against a primary or unique key. Excellent for joins.
• ref — all rows matching an index value are read using a non-unique index or a leftmost prefix. Very good, and the realistic target for most equality predicates.
• range — rows in a bounded interval are retrieved through an index, as with BETWEEN, IN, or comparison operators. Healthy when the range is selective.
• index — a full scan of the index tree. Cheaper than a table scan because the index is smaller, but it still reads every entry.
• ALL — a full table scan. On a large table in a hot code path, this is the value that wakes people up at night.

When we audit a slow query, we scan the type column first and flag every ALL and unselective index on any table larger than a few thousand rows.

key, possible_keys, and key_len

possible_keys lists the indexes the optimizer considered, while key shows the one it actually chose. The most common red flag is a populated possible_keys with a NULL key — the optimizer had options and rejected all of them, usually because the predicate was not selective enough or the index could not be used as written. The key_len value tells you how many bytes of a composite index are actually being used, which is how you confirm whether a multi-column index is being exploited fully or only on its leading column.

rows and filtered

The rows column is the optimizer’s estimate of how many rows it must examine for that table, and filtered is the estimated percentage that will survive the WHERE condition. Multiply them across a join and you get a rough sense of the work involved. A plan that estimates examining two million rows to return fifty is doing far too much work, and that gap is precisely where tuning effort pays off.

select_type and Extra

select_type identifies the role of each query block — SIMPLE, PRIMARY, SUBQUERY, DERIVED, UNION, or the dreaded DEPENDENT SUBQUERY that signals a correlated subquery re-executing once per outer row. The Extra column, which we cover next, is where the optimizer confesses its sins.

Decoding the Extra Column

The Extra column carries the annotations that most often explain a mysteriously slow query. These are the values we treat as actionable signals:

• Using index — the query is satisfied entirely from the index without touching the table data. This is a covering index, and it is exactly what you want to see. Do not confuse it with the next two.
• Using where — rows are filtered after retrieval. Benign on its own, but combined with a high rows estimate it indicates the index is not narrowing the result set effectively.
• Using filesort — MySQL must perform an extra sorting pass because it cannot satisfy the ORDER BY from an index. Despite the name, this does not necessarily mean disk I/O, but on large result sets it frequently does.
• Using temporary — an internal temporary table is required, common with GROUP BY and DISTINCT combined with sorting on a different column. When temporary tables spill to disk, throughput collapses.
• Using index condition — Index Condition Pushdown is in effect, letting the storage engine evaluate part of the WHERE clause against the index before fetching full rows. This is an optimization, not a warning.
• Using join buffer — MySQL is falling back to a block nested-loop or hash join because no usable index exists on the join column. On joined tables of any size, this is a strong tuning candidate.

The pairing we hunt for most aggressively is Using temporary; Using filesort on a query that runs thousands of times per minute. That combination is a reliable indicator of an aggregation or sort that an index could eliminate.

EXPLAIN ANALYZE: From Estimate to Evidence

Standard EXPLAIN shows you what the optimizer intends to do. EXPLAIN ANALYZE, introduced in MySQL 8.0.18, actually runs the statement and reports what happened — real timings, real row counts, and the number of loops each iterator performed. This is where stale statistics get exposed, because you can directly compare the estimated rows against the actual rows returned.

EXPLAIN ANALYZE
SELECT o.id, o.total
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE c.region = 'APAC'
ORDER BY o.created_at DESC
LIMIT 50;

When the actual row count dwarfs the estimate, the optimizer was working from a bad model of your data and likely chose a suboptimal join order or index. When a nested-loop iterator reports thousands of loops, you have found your bottleneck. Because EXPLAIN ANALYZE executes the query, we run it against a representative non-production replica for write statements or any query whose side effects we are not prepared to incur. The full behaviour is described in the EXPLAIN statement reference.

A Practical Tuning Workflow

Reading a plan is only half the discipline; the value is in what you change. The workflow our team applies, refined across hundreds of production engagements, follows a consistent sequence.

1. Confirm the statistics are current

Before blaming the query, run ANALYZE TABLE on the tables involved to refresh the index statistics the optimizer relies on. A surprising share of “bad plan” tickets evaporate the moment cardinality data is brought up to date after a large bulk load or data migration.

2. Make the predicate sargable

An index cannot be used if you wrap the indexed column in a function. WHERE DATE(created_at) = '2026-05-27' forces a scan, whereas WHERE created_at >= '2026-05-27' AND created_at < '2026-05-28' lets the optimizer use a range scan on the index. Rewriting non-sargable predicates is often the highest-leverage change available, and it requires no schema modification.

3. Design composite indexes for the access pattern

Single-column indexes are rarely enough for real workloads. The order of columns in a composite index matters profoundly: place equality predicates first, then the range or sort column. An index on (customer_id, created_at) can serve both the filter on customer_id and the ORDER BY created_at in a single structure, eliminating a filesort. When the index also contains every column the query selects, you achieve a covering index and the table read disappears entirely.

4. Reshape the query, not just the schema

A correlated subquery showing as DEPENDENT SUBQUERY frequently performs an order of magnitude better when rewritten as a join or a derived table. Likewise, replacing OR conditions across different columns with a UNION of selective queries can let each branch use its own index. The plan tells you which rewrite the engine will reward.

5. Validate under realistic concurrency

A plan that looks pristine on an idle staging box can behave very differently when buffer pool contention, lock waits, and replica lag enter the picture. We always validate tuning changes against production-like data volumes and concurrency before declaring victory.

Common Anti-Patterns We See in Production

Across engagements, we see the same handful of mistakes recur. Leading wildcards in LIKE '%term' predicates that prevent index use. SELECT * that defeats covering indexes and bloats network and memory. Implicit type coercion — comparing a VARCHAR column to a numeric literal — that silently disables an index. And over-indexing, where a table accumulates a dozen redundant indexes that slow every write and confuse the optimizer’s choice. Each of these is visible in the execution plan once you know the signals to look for.

When to Bring in Specialist Help

Execution plan analysis scales well until it doesn’t. When you are tuning a single query, the techniques above are sufficient. When you are facing systemic regression across thousands of statements, replication lag under peak traffic, or a schema that has outgrown its original design, the problem shifts from query tuning to architecture. That is the work we do every day at MinervaDB. Our MySQL consultative support and MySQL performance engineering practices exist precisely for the moments when a faster query is no longer enough and you need a faster system. You can review our broader approach to MySQL DBA support and remote operations as well.

Closing Thoughts

The execution plan is the most honest document MySQL produces. It does not care how elegant your SQL looks or how confident the developer was that the index would be used. It reports what the optimizer decided, and with EXPLAIN ANALYZE, what actually happened. Engineers who read it fluently spend less time guessing and more time fixing.

Make EXPLAIN a reflex, not a last resort. Run it before you ship a query, not after it pages you at two in the morning. Keep your statistics fresh, design indexes for your real access patterns, and let the plan — not intuition — guide your tuning. Do that consistently, and the queries that once defined your incident reports will quietly become the fastest part of your stack.

Need a second set of expert eyes on a stubborn workload? Talk to the MinervaDB team about a MySQL performance review.

The history of computing is littered with the remains of forgotten operating systems—some rendered obsolete by technological progress, some that never quite captured the public imagination, and some just so aggressively useless that everyone would rather forget they ever existed. But we shouldn’t forget! And happily, there’s a new project devoted to preserving the history of all manner of strange and wonderful OSes: the Virtual OS Museum, a repository of some 1700 operating systems that date back to the dawn of computing as we know it.

This project is all the more remarkable for being the work of one man: Andrew Wartenkin, who has been collecting OS images for over two decades. Of course, Wartenkin didn’t write all the emulation software himself, and he maintains a list of credits to give credit where it’s due. But the work of collecting all the Museum’s material, making sure the various emulations work, and creating a single, fairly seamless point of entry for people interested in exploring them—that’s all Wartenkin.

If you’re interested in having a look yourself, you should know that the Museum isn’t a website where you can just click through to different OS emulations: you need to download and install the project on your computer, and you might need to do a bit of hacking to get it to work.

It’s worth the effort, though, because there’s a ton of fascinating history here to play with. The Museum itself runs in a virtual machine, which seems kinda fitting—it opens in a virtualized Linux installation and presents you with the full list of available operating systems. Did you know someone has written a GUI for the Commodore 64? Neither did I!

There are simulations of ancient mainframes, like the IBM 1130 (yours for the low, low price of $32,280—or $41,230 with a disk drive—back in 1965). And then there are the truly esoteric ones, like the GIER, which, as far as I can tell, was an early transistor-based calculator built in the mid-1960s by Danish company Regnecentralen—most famous for their RC-4000 operating system, which is also included—and sold only in Germany:

Perhaps you’ve always wondered about the IBM 5110, an early attempt at a portable computer? Well, place a stack of cinderblocks on your lap and then boot up the 5110 emulator! which truly stretched the definition of “portable.” Or perhaps you’ve always wondered what it’d be like to play around with the late Terry Davis’s batshit crazy decidedly idiosyncratic TempleOS? Er—well, that one will have to wait, because it doesn’t work at the moment.

Now, as I mentioned, getting started will take a little work. There are two downloads to choose from. As well as the “Full” version, which weighs in at 175 GB when unzipped and contains the entire archive, there’s a “Lite” version, which contains everything you need to get the museum up and running but not the actual OS images themselves—they are downloaded automatically when you choose whichever one you’d like to run. The Lite version is only 21GB unzipped, so unless you’ve got storage space to burn, I’d recommend it over the whole shebang. I’d also recommend using the provided BitTorrent files to download the archive, because they’re a lot faster than the direct download server.

Once you’ve downloaded and extracted the archive, you can move on to getting the Museum up and running. For me, at least, this wasn’t super straightforward, though the issues I encountered are apparently known to Wartenkin and will be fixed in an upcoming version.

For now, the main problem seems to be with VirtualBox’s management of file locations. It needs two large .vdi files to run, and it insists on looking for them in one place only—presumably their original location on Wartenkin’s computer—rather than in the location where you’ve actually extracted them. You can get around this issue by creating a couple of symbolic links to the files. The way to do this will depend on your actual operating system. If you’re on Windows and comfortable with the command prompt, you can use mklink to create links to the files:

mklink "C:\data1\common1\disk_images\os_museum_vm\dist\virtual_os_museum-2026.05.19-lite\VirtualOSMuseum.utm\Data\host_x86.vdi" “[actual path]”

([actual path] is the location of the file on your computer.)

If you’re on macOS or Linux, you can do something similar in the Terminal using the ln command. And if you’re wondering whether you can just create shortcuts to do this: no, you can’t. Well, not on Windows, at least, because I tried it and it doesn’t work.

It’s remarkable that this is all the work of one developer, because it’s often a significant amount of work to get one ancient OS working under emulation, let alone hundreds of them. With that said, I do hope that the project arrives at a place where it’s a little more user-friendly, because it’s a hugely valuable endeavor, and it’d be great if it were easy for casual users to explore with a minimum of friction. We look forward to future updates!

The best 3D modeling software for 3D printing depends on what you are making and how you like to work. A functional bracket, a tabletop miniature, and a replacement knob each reward a different kind of tool, and the right pick also turns on your budget, your operating system, and how much of a learning curve you can stomach. This guide sorts the 2026 field into the categories that actually matter: parametric CAD for precise mechanical parts, sculpting apps for organic shapes and miniatures, and the fast-rising wave of AI model generators. Each entry lists the current price, the license fine print that catches people out, and who it is genuinely for. Every program here exports geometry a slicer can read; where a tool needs help producing a clean, watertight model, we flag it.

There is no single winner, so we name a best pick for each job. If you only remember one thing: pick a parametric tool when dimensions and fit matter, and a sculpting tool when the shape is organic. Most of our picks have a genuinely free tier, and we weight print readiness (clean STL, 3MF, and STEP export, manifold output), real cost including license terms, learning curve, and platform support.

• Clean export. The tool should write STL and ideally 3MF and STEP without leaving holes or flipped faces. Solid and parametric modelers do this by construction; mesh and sculpting tools need a manifold check before export.
• Real units and scale. A model designed at the wrong scale prints at the wrong size. Tools that work in millimetres with reliable dimensions save reprints.
• The right paradigm for the job. Parametric CAD for parts that must fit together, mesh or sculpting for figures and art. Forcing one to do the other is where beginners stall.
• Honest licensing. “Free” can mean genuinely free, free with a document cap, or free but every file is public. We spell out which is which.
• Active development and a community. A tool with recent releases and a searchable user base is one you can actually get unstuck in.

• Parametric modeling. You build a part from dimensioned sketches and features (extrude, fillet, hole) that stay editable. Change a number and the model updates. The standard approach for mechanical and functional parts.
• Mesh modeling. You work directly with a surface made of triangles or polygons. Flexible for organic forms, but you have to watch for non-manifold geometry before printing.
• Sculpting. You push, pull, and carve a high-resolution mesh like digital clay. The route to characters, busts, and miniatures.
• NURBS and sub-D. Two ways of describing smooth, curved surfaces used in product and concept design (Plasticity and Shapr3D lean on these).
• STL, 3MF, STEP, OBJ. Common export formats. STL is the universal mesh format, 3MF is the newer replacement that also carries colour and print settings, STEP is the precise format for CAD parts, and OBJ carries texture data for sculpts.
• Manifold and watertight. A printable mesh with no holes or self-intersections. Slicers need it to tell inside from outside.

Best 3D modeling software for 3D printing at a glance

One standout per job. New to this and just want to start? Open Tinkercad in a browser today; step up to Autodesk Fusion (free for personal use) when you outgrow it.

Securing MySQL Data at Rest: Architecture, Concepts, and Why It Matters

In today’s data-driven environments, protecting sensitive information is no longer optional, it is foundational. While organizations invest heavily in access controls and network security, one critical area is often misunderstood: data-at-rest encryption in MySQL.

Data-at-rest encryption ensures that even if database files are accessed outside MySQL through disk theft, backup exposure, or filesystem compromise, the data remains unreadable. This post explains how MySQL implements encryption internally, what it protects, and why a well-designed encryption strategy is necessary for modern systems.

Understanding the Real-World Threat Model

Before configuring encryption, you must understand the exact risks it mitigates. Data-at-rest encryption in MySQL protects against scenarios such as:

‍

However, encryption operates exclusively at the storage layer. It does not protect against:

• Valid database users executing queries.
• Application-level vulnerabilities.
• Compromised database credentials.

‍

How MySQL Implements Data-at-Rest Encryption

MySQL utilizes InnoDB storage engine encryption (External Link), which is designed to be transparent to applications and highly efficient at runtime.

Key Characteristics:

• Encryption is applied at the tablespace level.
• Data is encrypted at the page level.
• All encryption and decryption operations occur entirely in memory (within the InnoDB buffer pool).
• Plaintext data is never written to the physical disk.

This design ensures that your applications require absolutely no code changes, maintaining strong protection at the storage level without sacrificing usability.

Encryption Architecture: A Layered Approach

MySQL relies on a hierarchical key structure to manage encryption securely.

Key Hierarchy

1. Master Key: Stored securely in the MySQL keyring.
2. Tablespace Key: A unique key generated for each individual tablespace.
3. Encrypted Data Pages: The actual user data stored on disk.

How It Works:
Each tablespace is encrypted using its own unique tablespace key. To secure the system further, the tablespace key is then encrypted using the master key. Finally, the master key is stored in the keyring. This layered approach improves overall security and allows administrators to rotate keys efficiently without needing to re-encrypt entire tablespaces.

What Should Be Encrypted in MySQL

A complete encryption strategy involves much more than just securing your tables.

To prevent data leaks, the following components must be considered:

1. Tablespaces: These hold the actual user data and are the primary target for encryption.
2. Undo Tablespaces: Undo logs store previous versions of rows, which may include deleted or modified data. Encrypting them stops the exposure of historical data.
3. Redo Logs: Redo logs capture recent database changes and transaction history. They often contain highly sensitive before-and-after values.
4. Binary Logs: Binary logs track all database modifications. They are essential for MySQL replication (Internal Link placeholder) and point-in-time recovery.
5. Relay Logs: Existing on replica servers, relay logs mirror the primary server’s binary logs, making them equally sensitive.

Encrypting only your tablespaces leaves these other layers heavily exposed. Full coverage guarantees your data is protected across all storage components.

Key Management: The Core of Encryption

Encryption is only as strong as its key management. The MySQL keyring carries several vital responsibilities:

• Storing the master encryption key.
• Enabling the encryption and decryption of tablespace keys.
• Supporting secure key rotation.

Example Configuration (MySQL 8.0)

early-plugin-load=keyring_file.so
keyring_file_data=/secure/keyring/keyring

Verification

SHOW PLUGINS;

Expected output:

keyring_file | ACTIVE

Best Practices for Keyring Management:

• Store keyring files with strictly restricted OS permissions.
• Keep your keyring storage logically and physically separate from your database files.
• Always include the keyring in your database backup strategy (Internal Link placeholder).

MySQL 8.0 vs MySQL 8.4: Evolution of the Keyring

MySQL 8.4 introduces a modern, component-based keyring system, shifting away from the older plugin methods.

• MySQL 8.0: Utilizes a plugin-based approach, which requires the plugin to be loaded early during server startup (early-plugin-load).
• MySQL 8.4: Utilizes a component-based architecture, offering better flexibility, easier configuration, and long-term maintainability.

Verification in MySQL 8.4

SELECT * FROM performance_schema.keyring_component_status;

Why Data-at-Rest Encryption Is Essential

Implementing encryption extends beyond basic security. It actively supports:

• Regulatory Compliance: Meeting strict standards for PCI-DSS, GDPR, and HIPAA.
• Accidental Exposure Prevention: Stopping data leaks from misplaced backups or retired hardware.
• Defense Against Infrastructure Threats: Adding a final layer of protection against hardware and OS-level breaches.

Modern infrastructure planning must assume that storage layers could eventually be accessed by unauthorized parties.

Conclusion

Data-at-rest encryption in MySQL provides a reliable method to defend sensitive data from unauthorized file-level access. However, its actual effectiveness relies on a complete approach. You must encrypt all relevant database components, manage your encryption keys safely, and clearly understand the scope and limitations of the feature. When set up correctly, data-at-rest encryption acts as a necessary layer in a defense-in-depth strategy.

Data-at-rest encryption in MySQL is a foundational defense-in-depth strategy that protects sensitive information from physical disk theft, backup exposure, and unauthorized filesystem access by ensuring plaintext data is never written to disk. Utilizing InnoDB’s transparent, layered architecture, it secures data via a master key stored in a keyring—which has evolved from a plugin system in MySQL 8.0 to a modern component-based model in MySQL 8.4—to safely encrypt individual tablespace keys.

To achieve true regulatory compliance (like GDPR or HIPAA) and robust security, organizations must extend this encryption beyond standard tablespaces to include undo logs, redo logs, binary logs, and relay logs, ensuring complete data protection backed by strict, isolated key management practices.

Secure Your MySQL Infrastructure

Ensure your database meets strict compliance standards and is fully protected against file-level threats. Our experts at Mydbops are ready to audit, configure, and manage your MySQL encryption strategy.

Implementing MySQL Data-at-Rest Encryption

Implementing encryption in MySQL requires careful planning, correct configuration, and operational discipline. While the feature itself is straightforward, a production deployment involves multiple components such as keyring setup, table encryption, log encryption, backups, and performance validation.

This guide provides a detailed, step-by-step approach to configuring MySQL data-at-rest encryption in a production environment, focusing on the latest standards in MySQL 8.4.

Phase 1: Setting Up the Keyring (MySQL 8.4 Component-Based Approach)

In MySQL 8.4, the keyring architecture transitioned from a plugin-based model to a component-based framework. This update improves flexibility, maintainability, and compatibility with modern MySQL infrastructure.

Unlike MySQL 8.0, where early-plugin-load was necessary, MySQL 8.4 uses a component manifest and configuration file. The keyring initializes automatically during server startup.

1. Understanding the Keyring Components

The keyring setup in MySQL 8.4 involves four main elements:

• Component: component_keyring_file
• Configuration file: component_keyring_file.cnf
• Data file: component_keyring_datafile
• Manifest file: mysqld.my

These elements work together to ensure the keyring loads before InnoDB initializes.

‍

2. Create Keyring Configuration File

First, create the configuration file to define where the database will store the keyring data.

vi /etc/mysql/component_keyring_file.cnf

Add the following configuration:

{
 "path": "/secure/keyring/component_keyring_datafile"
}

‍

3. Create and Secure the Keyring Directory

Create the directory and assign the correct ownership and permissions. This prevents unauthorized OS-level access.

mkdir -p /secure/keyring
chown -R mysql:mysql /secure/keyring
chmod 700 /secure/keyring

‍

4. Create the Manifest File

The manifest file instructs the server to load the keyring component at startup.

vi /var/lib/mysql/mysqld.my

Add the following content:

{
 "components": "file://component_keyring_file"
}

‍

5. Restart MySQL Service

Apply the changes by restarting the MySQL service.

systemctl restart mysqld

‍

6. Verify Keyring Component Status

Run the following query to confirm the keyring is active.

SELECT * FROM performance_schema.keyring_component_status;

Expected Output:

component_keyring_file | ACTIVE | YES

This output confirms the keyring component is operational.

Phase 2: Enabling Tablespace Encryption

With the keyring in place, you can now encrypt your data. Tablespace encryption protects your tables at the storage level.

Encrypt New Tables

Specify the encryption clause when creating a new table.

CREATE TABLE customers (
 id INT PRIMARY KEY,
 name VARCHAR(100)
) ENCRYPTION='Y';

Encrypt Existing Tables

‍Alter existing tables to enable encryption.

ALTER TABLE customers ENCRYPTION='Y';

Set Global Default

‍To force encryption for all new tables automatically, adjust the global variable.

default_table_encryption=ON

Verify Encryption

‍Check the encryption status of your tables using the information schema.

SELECT NAME, ENCRYPTION FROM information_schema.INNODB_TABLESPACES;

🔗 Fulfilled Tablespace Encryption (TDE) in Percona Cluster For teams running Percona XtraDB Cluster who need to apply TDE across nodes.

🔗 Shield Your Sensitive Data: MySQL Data Encryption at Rest A webinar recap covering encryption at rest concepts — good supplementary read for teams new to the topic.

Phase 3: Encrypting Logs

To achieve complete data-at-rest protection, you must also encrypt the database logs. Unencrypted logs can expose sensitive data even if the tablespaces are secure.

Redo Log Encryption

innodb_redo_log_encrypt=ON

Undo Log Encryption

innodb_undo_log_encrypt=ON

Binary Log Encryption

binlog_encryption=ON

🔗 How to Use the MySQL 8.4 Audit Log Filter Key rotation and encryption events should be captured in audit logs — this guide explains how to set up granular audit filtering in MySQL 8.4.

Phase 4: Master Key Rotation

Periodic key rotation is a standard security requirement. Rotating the master key generates a new key and re-encrypts the tablespace keys, but it does not require re-encrypting the actual table data.

ALTER INSTANCE ROTATE INNODB MASTER KEY;

‍

Backup and Recovery Considerations

Encryption directly affects how you handle backups and recovery. Keep these principles in mind:

• Physical backups must include the keyring.
• Losing the keyring makes encrypted data permanently unrecoverable.
• Logical backups (like mysqldump) export data in plaintext and are not encrypted by default.

Example Keyring Backup Command:

cp /secure/keyring/keyring /backup/keyring

‍

Performance Impact and Benchmarking

Encryption adds a measurable workload to your database server. Before deploying to production, benchmark the performance impact in a staging environment.

Common observations include:

• Query latency increases moderately.
• Commit latency increases slightly due to redo log encryption.
• Overall CPU and I/O usage will rise.

Example Metrics:

• Average query latency: 12.3 ms → 14.7 ms
• Commit latency: 1.2 ms → 1.8 ms

‍

Operational Best Practices

To maintain a secure and stable environment, follow these operational rules:

• Restrict OS-level access: Limit access to the database data directory and the keyring folder.
• Enforce minimal privileges: Apply the principle of least privilege for all database users.
• Align replication nodes: Ensure encryption configurations are identical across all primary and replica nodes.
• Monitor status regularly: Track the state of your keyring and encryption variables as part of your routine checks.

🔗 Fastest Parallel Replication in MySQL 8For teams aligning encryption settings across replication nodes, this explains replication internals relevant to that process.

Common Pitfalls to Avoid

Many encryption issues surface only during a critical incident. Avoid these frequent mistakes:

• Failing to back up the keyring file.
• Skipping routine recovery tests.
• Forgetting to enable binary log encryption.
• Deploying to production without proper performance benchmarking.

These oversights often lead to costly delays or permanent data loss during a recovery scenario.

Conclusion

Implementing MySQL data-at-rest encryption is a structured process that extends beyond simple configuration. It requires strict attention to key management, operational workflows, and performance validation.

A well-planned execution ensures that your data remains completely secure, even in the event of a physical or storage-level compromise. For additional context on official specifications, consult the MySQL 8.4 Reference Manual on InnoDB Data Encryption.

Protecting your data at rest is just one part of a robust database strategy. Mydbops provides comprehensive MySQL support, ranging from 24/7 managed services and remote DBA assistance to architectural consulting and thorough security audits. Let our team handle the operational complexities and performance tuning to eliminate bottlenecks and keep your infrastructure secure.

Reach out today to secure and optimize your database environment.

Amazon Aurora MySQL-Compatible Edition now supports MySQL 8.4, a community MySQL Long Term Support (LTS) major version. Aurora MySQL 8.4 launches with compatibility for community MySQL 8.4.7 and introduces aligned version numbering, so the version number you run on Aurora matches the community MySQL version it is compatible with. Aurora also manages the underlying patch on your behalf, simplifying day-to-day operations. Aurora MySQL now targets major versions within 12 months of community MySQL LTS releases, minor versions within 3 months of each community minor, and an Aurora LTS minor within 12 months of each major. For engine specific release objectives, see the Aurora and RDS open source release calendar announcement.

Aurora MySQL 8.4 strengthens security defaults for new clusters. TLS is enforced by default with only TLS 1.2 and 1.3 supported, new accounts use the caching_sha2_password authentication plugin, and password validation policies are customizable through DB cluster parameter groups. Automated upgrade prechecks identify compatibility issues before your cluster goes offline, giving you confidence before you upgrade. To learn more about the Aurora MySQL 8.4 customer experience, refer to the Aurora MySQL 8.4 launch announcement blog.

You can upgrade your database using Amazon RDS Blue/Green Deployments, in-place upgrade, or restore from a snapshot. Learn more about performing major version upgrades in the Amazon Aurora User Guide. You can also migrate to Aurora MySQL 8.4 from external MySQL sources using AWS Database Migration Service or Percona XtraBackup. Aurora MySQL 8.4 is available in all AWS Regions where Aurora MySQL is available.

Amazon Aurora MySQL is designed for unparalleled high performance and availability at global scale with full MySQL compatibility. It provides scale-to-zero serverless compute, Aurora Global Database for Multi-Region resilience, Aurora I/O-Optimized for improved price performance on I/O-intensive workloads, and built-in security and continuous backups. To get started with Amazon Aurora, take a look at our getting started page.