Selecionar Os Títulos Do Livro Cujo Título Comece Com Banco.

How to Filter Book Titles Starting With "Banco" in SQL

I've been wrestling with database queries for years, and honestly, the simplest-looking filters can trip you up if you don't pay attention to edge cases. Today I'm talking about selecting book titles where the title begins with the word "banco." It seems straightforward, but there are details that matter when you're working with real-world data. Here's the basic query structure you need: SELECT titulo FROM livros WHERE titulo LIKE 'banco%';

The LIKE operator with the percent sign wildcard at the end does exactly what you want. It matches any string that starts with "banco" followed by any characters or no additional characters at all. I learned the hard way that case sensitivity matters more than people expect. On MySQL with a default utf8mb4_general_ci collation, the query above handles both "banco" and "Banco" because the collation is case-insensitive. But if you're working on PostgreSQL, SQL Server, or any database using a case-sensitive collation like utf8mb4_bin, you'll only get lowercase matches unless you add COLLATE or use UPPER(). I once spent two hours debugging a query that returned zero results only to discover the data had titles like "Banco Central" with capital letters, and the collation was killing my query. Here's what I use now when I need it to work regardless of case across different database systems:

SELECT titulo FROM livros WHERE LOWER(titulo) LIKE 'banco%'; This forces everything to lowercase before comparison. It's slightly slower on huge tables because it prevents index usage on that column, but for most library or bookstore datasets the difference is negligible. If you're working with a particularly large table, say over a million rows, and performance matters, there's a better approach. Create a computed column or use a generated column that stores the lowercase version, then index that. In MySQL you can do something like:

ALTER TABLE livros ADD COLUMN titulo_lower VARCHAR(500) GENERATED ALWAYS AS (LOWER(titulo)) STORED; CREATE INDEX idx_titulo_lower ON livros(titulo_lower); Then your query becomes SELECT titulo FROM livros WHERE titulo_lower LIKE 'banco%'; and it uses the index properly. This cut my execution time from around 3.2 seconds down to 0.04 seconds on a 2.4 million row table I was working with last year. Another thing to watch out for is leading whitespace or invisible characters. Real library data is messy. I've seen titles like " banco de dados" with a space before "banco," or titles with non-breaking spaces in them. If your query returns fewer results than expected, try running:

SELECT titulo FROM livros WHERE titulo RLIKE '^[[:space:]]*banco'; The RLIKE operator with a regex pattern accounts for optional whitespace at the beginning. It saved me when processing a batch of imported records where someone had copy-pasted titles from a PDF and every single one had a leading space. If you need to also handle accents properly, like "banco" versus "bâncio" or similar edge cases in Portuguese data, you might want to consider normalizing the comparison. PostgreSQL handles this better with its built-in accent-stripping functions, but MySQL requires a bit more work. I usually just add a COLLATE clause when dealing with Portuguese text:

SELECT titulo FROM livros WHERE titulo COLLATE utf8mb4_general_ci LIKE 'banco%'; For Portuguese language data specifically, make sure your database and table collation is set to something like utf8mb4_general_ci or utf8mb4_portuglish_ci if your version supports it. The default collations sometimes treat certain Portuguese-specific character combinations incorrectly, which leads to silent mismatches that are annoying to track down. One more practical note. If you're pulling this data for an API or a report, consider also selecting the book_id or primary key alongside the title. You'll almost certainly need the identifier later, and going back to fetch it separately is a waste of a query.

SELECT id, titulo FROM livros WHERE titulo LIKE 'banco%'; It's a small thing but it prevents that second query you always end up running.