Sharding is a technique used to scale databases horizontally by dividing data across multiple separate databases or servers, called shards. Each shard contains a subset of the data, typically partitioned by a logical key such as region, user ID, or another attribute. By distributing the data this way, you can handle more requests, store more data, and reduce the load on any single database instance. Sharding is especially useful for large-scale applications where a single database server would become a bottleneck, either due to storage limitations or performance constraints.

-- Example: Sharding 'customers' data by region across two databases (simulated with two tables)

-- Customers from North America are stored in the 'customers' table
SELECT * FROM customers WHERE name IN ('Alice Smith', 'Bob Johnson', 'Carol White');

-- Customers from Europe are stored in the 'customers_shard2' table
SELECT * FROM customers_shard2 WHERE name IN ('David Brown', 'Eva Green');

When using sharding, your application must know how to route queries to the correct shard. This is often done by applying a sharding key, such as region or customer ID, to determine which database or table to use. Maintaining data consistency across shards can be challenging, since transactions and joins that span multiple shards require special handling. Some operations, like aggregating data across all customers, may become more complex and require querying each shard separately and then combining results at the application level.

-- Routing queries to the correct shard based on region

-- Querying a customer in North America (shard 1)
SELECT * FROM customers WHERE email = 'alice@example.com';

-- Querying a customer in Europe (shard 2)
SELECT * FROM customers_shard2 WHERE email = 'eva@example.com';