go-sql-driver

mysql

Go2013–2026

go-sql-driver / mysql

mysql

Go MySQL Driver is a MySQL driver for Go's (golang) database/sql package

Data & Databases

Explore on GitHub Read Hacker News discussions

8Distinct people

8Mentions

0Explicit recommenders

15.3KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Go MySQL Driver is a MySQL driver for Go's (golang) database/sql package

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year8 dated mentions

Observed mentions: 2013-03-25 22:17:10 UTC to 2026-05-04 21:13:23 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2013	2013-01-01 00:00:00 UTC	2014-01-01 00:00:00 UTC	2	2
2014	2014-01-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	2	2
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	0	0
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	0	0
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	1
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	1
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	0	0
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	1

What Hacker News says

8 sources

nemothekid·May 4, 2026

Thats the default for go projects. Go imports are repository strings (e.g.): import ("github.com/go-sql-driver/mysql") so it's standard to have the library files in the root directory.

In How OpenAI delivers low-latency voice AI at scale

evanelias·Mar 6, 2022

> mysql_real_escape_string is still vulnerable when being used with some exotic character sets Indeed -- mysql_real_escape_string "mostly" fixes this problem by requiring a db connection as one of its args. Since the driver is usually aware of the connection state, mysql_real_escape_string can check to see if one of those exotic charsets is in-use. The issue is that there are multiple ways to change the connection charset, some of which the driver is aware of (e.g. in PHP mysqli set_charset) but some it is not (running textual statements like SET NAMES or SET CHARACTER SET). However, generally an attacker won't have the ability to set an arbitrary exotic character set for the connection anyway... unless they already have some other sql injection mechanism, in which case it's a moot point :) Driver documentation also typically mentions thi

Read the rest

s problem. For example, here's the doc for doing client-side param interpolation in the most popular MySQL driver for Golang: https://github.com/go-sql-driver/mysql#interpolateparams (see warning in italics) It also explicitly detects if your initial connection settings attempt to use one of those charsets along with param interpolation, and throws an error if so: https://github.com/go-sql-driver/mysql/blob/21f789cd/dsn.go#... > Couldn't one just save the extra round-trip with length-prefixed strings by sending the query together with the parameters in a single message? AFAIK, no, not with the traditional MySQL binary protocol. The newer "X protocol" introduced in MySQL 5.7 does allow this, but it is not widely implemented in drivers.

In Finding an authorization bypass on my own website

user5994461·May 21, 2020

It's funny you say it resolves the problem because if you read the bug report from the author opened since 2017 https://github.com/go-sql-driver/mysql/issues/657 It's repeatedly pointed out by one maintainer that his server and application are misconfigured and should be fixed. Yet the author doesn't consider it and goes on a project to redo the connection pool (the library can certainly benefit from better error detection but he would be better off fixing the root cause of connections dropping). Ergo the issue is not fixed. If you look at the chart provided, it's still erroring every few minutes, instead of every minute. It's an improvement but a far cry from zero. https://user-images.githubusercontent.com/42793/57318792-6e3...

In Three bugs in the Go MySQL driver

laumars·Jun 30, 2017

Are they actually frowned upon? I've been writing Go for a few years now and while I acknowledge there will be blind spots in my knowledge, this is still the first I've heard against using that language feature. In fact named returns appear all over the Go source code itself[0] and the Effective Go section on named returns[1] seems positive about their usage. [0] https://github.com/golang/go/blob/master/src/os/file.go (file taken at random) [1] https://golang.org/doc/effective_go.html#named-results Personally I use named returns heavily because it helps document what each return is used for. Which is particularly useful in IDEs like IntelliJ where you get the tooltip popup with the function parameters and returns. But frankly I find named returns just as useful when reading back old code on GitHub or even just in vi. I also notice I'm not

Read the rest

the only one who uses them in production code. Here are some popular packages by other talented Go developers (all .go files picked at random)[2][3]: [2] https://github.com/kr/pty/blob/master/util.go (this package creates UNIX PTY files) [3] https://github.com/chzyer/readline/blob/master/operation.go (readline package used by cockroachdb and Netflix) In fact of the packages I checked, I could only find one package that didn't make heavy use of named returns[4] [4] https://github.com/go-sql-driver/mysql/ So if they are frowned upon, I'd be interested to know more about who and why.

In Benefits of named return values in Go

shadowmint·Oct 6, 2014

See... that's the thing. It might work. If the driver plays nicely. Or it might not. In fact, you have no way of knowing without reading the source code. The sqlite driver used to not work with the postgres one. I don't know why. I never looked into it... but, that this can happen is pretty bad, I'd argue. Packages that invoke code when you import them and require this sort of import: import _ "github.com/go-sql-driver/mysql" Aren't idiomatic. They're hacks, because the database module didn't really consider how it was going to work properly.

In A survey of the current state of Golang ORMs

tokenizerrr·Oct 5, 2014

I'm confused. sql.Open's first argument is which driver you want to use, in string format. These drivers become available after they've been imported, and the side effects seem insignificant[1]. This seems to make it perfectly possible to use multiple drivers within the same scope. The drivers themselves also seem to have several unit test files, though I can't judge on the quality of those. [1] https://github.com/go-sql-driver/mysql/blob/master/driver.go...

In A survey of the current state of Golang ORMs

voidlogic·Apr 22, 2013

The most likely cause is in the mysql driver. Go provides an interface for drivers to implement, similar to how JDBC does in Java. One of the go developers, Brad Fitzpatrick, commented [1] that the actual code used by the benchmark looks OK. The discussion of these test results on golang-nuts [1] triggered a number of performance related pull requests [2] to the mysql driver used. Also of interest: https://code.google.com/p/go/issues/detail?id=5323 1: https://groups.google.com/forum/?fromgroups=#!topic/golang-n... 2: https://github.com/go-sql-driver/mysql/pull/52 https://github.com/go-sql-driver/mysql/pull/55

In Web Framework Benchmarks Round 3

mortdeus·Mar 25, 2013

Your entire argument is invalid. "I don't think this is a reasonable demand for startups or even medium sized businesses." It was a recommendation. Go is a great investment, and while it may not have a "huge" market share, many of the most influential tech company's in silicon valley are starting to use Go. https://code.google.com/p/go-wiki/wiki/GoUsers And some of these companies are even writing/rewriting their spotlight core projects with Go. https://code.google.com/p/go-wiki/wiki/SuccessStories "Libraries cost time and money to produce" Time yes, Money no. Developers may charge money to produce software, however there are lots of software projects out there that were written by developers who worked for free. Does a painter always paint with the intention to sell his/her work at a gallery showing? Maybe they just want to create someth

Read the rest

ing for other people to experience. I view all software from this perspective, and I give alot of my time working on go boilerplate libraries and other opensource projects for free because I want to help empower developers to create real world solutions to real world problems without the nuance of having to "invent the wheel before being able to engineer a new automobile". "and if you are relying on free volunteers, development will either be slow or buggy and likely both." Pass. "I remember when I tried to look into a MySQL library last month. The first one I tried wouldn't even compile. The 2nd one threw a connection error not when I issued the dial function, but when I tried a query on a fake IP." Have you tried reading https://code.google.com/p/go-wiki/wiki/SQLDrivers, or... perhaps considering using one of these, http://godoc.org/?q=sql Maybe consider this which looks considerably up to date. https://github.com/go-sql-driver/mysql Your experience last month with Go may very well be irrelevant now. Ive been using Go for about a year now, and many things have changed within go's development ecosystem within that time period. If you arent willing/capable of contributing to go by committing code, thats perfectly fine. However, atleast make sure that your issues with the language are actually still relevant before you discourage other developers from exploring the language themselves. "If you want Go to succeed" As if its likely to fail? Go has already successfully satisfied the language designer's desires that motivated the project's creation. They want to create a language that makes their programming environment more enjoyable and efficient when developing software at a scale Google operates at. Unless some language comes along that is exceptionally better at solving the problems Go was design to solve, Go will remain a successful programming language for those who use it. "get Google to start funding it more" Are you kidding me? Google has some of the most well respected engineers in computational history working full time on Go. Google cant just walk into best buy and hire geek squad to work on Go. We are trying to reduce go's overall source code complexity so that we can not only maintain the code, but ensure we dont introduce bad language design mechanics as apart of the programming environment. We want to avoid the situation, years down the road., where we are faced with having to make a decision to either cope with a bad language mechanic or deal with it by introducing backwards incompatible changes that break gopher's code. Both options suck, and the only good option is to avoid the situation entirely by making sure we make the best design choices. "or get used to having it grow organically like every other language." Most languages dont grow organically. Most either grow all mutated and exponentially complex to adapt to changes in technology, or development either slows down or stops growing completely because the majority developers who used the language, moved on to something . Go on the other hand does grow organically, atleast it has so far. Everyday the project matures and issues we are frustrated with right now could be a faux problem because its already been fixed in go tip and you just need to rebuild the compiler. http://swtch.com/~rsc/go11.html I mean sure there are alot of bugs to fix and alot more than can be done to improve go's performance, but this is true for all software in general. The reason go is a good investment because it has alot of good investors investing in it.

In Zero-downtime restarts in Go