MySQL Relational Database Server and Its Tools
View All Tags
A table with a dozen columns doesn't fit in a terminal, and the mysql client's boxed output wraps into lines nobody can read. Ending the statement with \G instead of ; prints each row vertically, one column: value per line. This guide shows the difference on a real MySQL 9.7 table, and the client option that makes every result vertical.
A CHECK constraint is a rule MySQL enforces on every row, such as "a price can't be negative". When something refuses to save with ERROR 3819, or you just want to know which rules a database already has, you need to list them. MySQL keeps them in two INFORMATION_SCHEMA tables, and neither one has everything on its own. This guide joins them, on a real MySQL 9.7 database, and shows the quicker way for a single table.
A foreign key ties a column to another table: a product's CategoryId must be the Id of a real category. Before you delete a row, rename a table or change a column, you need to know which foreign keys are involved and what MySQL will do with them. This guide lists them three ways on a real MySQL 9.7 database: for one table, for the whole database, and in reverse, every table that points at a given one.
Indexes decide how fast MySQL can find rows, and which values must be unique. SHOW INDEX lists them for one table, and INFORMATION_SCHEMA.STATISTICS lists them for a whole database, ready to filter. This guide runs both on a real MySQL 9.7 database created by EF Core, and explains how to read multi-column indexes, where the order of the columns matters.
When you need to know exactly what a MySQL table looks like, which columns, which types, what can be empty and which keys exist, three statements answer at different levels of detail. DESCRIBE gives a quick table of columns, SHOW CREATE TABLE gives the complete definition with every index and constraint, and INFORMATION_SCHEMA.COLUMNS lets you query the answer. This guide runs all of them on a real MySQL 9.7 table created by EF Core.
The first thing to check in a MySQL database is which tables it has. SHOW TABLES answers that in one line, and INFORMATION_SCHEMA.TABLES adds the details: storage engine, collation, size and an approximate row count. This guide runs both against a real MySQL 9.7 database and explains the one number in there you shouldn't trust.
Unable to create a 'DbContext' of type 'Dewiride.Inventory.Data.InventoryDbContext'. The exception 'Unable to resolve service for type 'Microsoft.EntityFrameworkCore.DbContextOptions`1[Dewiride.Inventory.Data.InventoryDbContext]' while attempting to activate 'Dewiride.Inventory.Data.InventoryDbContext'.' was thrown while attempting to create an instance. The useful part is the line printed just before it: the app's own startup code had failed, so EF Core's tools couldn't get the DbContext the normal way. Here's how I ran into it with a migrations bundle, why --connection didn't help, and the fix.
NU1608: Detected package version outside of dependency constraint: Pomelo.EntityFrameworkCore.MySql 9.0.0 requires Microsoft.EntityFrameworkCore.Relational (>= 9.0.0 && <= 9.0.999) but version Microsoft.EntityFrameworkCore.Relational 10.0.14 was resolved. The message spells out the problem: the newest Pomelo MySQL provider is built for EF Core 9, and the project runs EF Core 10. That isn't a version to nudge; it's a provider that doesn't support your EF Core yet.
I gave a column a case-sensitive collation with EF Core's UseCollation("utf8mb4_0900_as_cs"), created the migration, applied it, and dotnet ef printed Done. The column was still utf8mb4_0900_ai_ci, and MySQL still refused desks as a duplicate of Desks. Oracle's MySQL provider for EF Core leaves UseCollation out of the SQL it generates. Here's how I found that, what Oracle documents instead, and the migration that does change the column.
The migration '20261103044430_MakeDescriptionRequired' has already been applied to the database. Revert it and try again. If the migration has been applied to other databases, consider reverting its changes using a new migration instead. dotnet ef migrations remove checks the database before it deletes anything, and this migration was in it. The message holds both fixes: one for your own development database, one for every other database.
