Introduction

On OS X 10.7, mysql: command not found usually means the MySQL client exists but your shell cannot find it through PATH. The fix is normally to locate the real binary, add the right bin directory to your shell startup file, and confirm that scripts use the same path resolution as your terminal.

Find the Real MySQL Client

Before changing configuration, confirm where MySQL is installed. Older Mac systems often have leftovers from package installers, tarball installs, or previous upgrades.

sudo find /usr /usr/local -name mysql -type f 2>/dev/null
ls -l /usr/local/mysql/bin/mysql
/usr/local/mysql/bin/mysql --version

If the full path works but plain mysql does not, the installation is present and the problem is almost certainly your shell path.

Update PATH in the Correct Shell Profile

OS X 10.7 commonly uses bash, and Terminal usually reads ~/.bash_profile for login shells. Add the MySQL client directory there:

echo 'export PATH="/usr/local/mysql/bin:$PATH"' >> ~/.bash_profile
source ~/.bash_profile
mysql --version

Check which shell you are actually using:

echo $SHELL

If you edit the wrong startup file, the change will look correct on disk but never apply to new terminal sessions.

Add a Stable Symlink When Needed

Some tools assume command-line programs live under /usr/local/bin. A symlink can make MySQL easier to discover across different environments.

sudo ln -sf /usr/local/mysql/bin/mysql /usr/local/bin/mysql
which mysql
mysql --version

This is especially useful on older systems where shell startup behavior differs between terminal apps, login sessions, and scheduled jobs.

Separate Command Lookup From Server Access

Once the command resolves, test connectivity separately. Command discovery and database login are different problems.

mysql --version
mysql -u root -p -e "SELECT VERSION();"

If the first command works and the second fails, you are now dealing with credentials, socket configuration, or server state rather than PATH.

That distinction saves time. Many people reinstall MySQL immediately, when the real problem is only shell lookup. Verifying command resolution first keeps the troubleshooting path narrow and predictable.

Handle Multiple Installations Carefully

Legacy machines often have more than one MySQL binary. That can make mysql point to a stale version after an upgrade.

which -a mysql
/usr/local/mysql/bin/mysql --version
/usr/local/bin/mysql --version

When versions disagree, remove obsolete symlinks and keep one explicit location in your profile so terminal sessions and scripts use the same client.

Scheduled tasks deserve separate attention because cron and other non-interactive processes often run with a smaller PATH than your terminal session. When a maintenance script still fails after the terminal fix, call MySQL with its absolute path inside the script so command lookup is no longer ambiguous.

Common Pitfalls

• Editing ~/.bashrc when OS X 10.7 Terminal is actually loading ~/.bash_profile.
• Assuming the MySQL server is missing when only the client path is wrong.
• Keeping old symlinks after upgrading MySQL and accidentally running the wrong binary.
• Forgetting that cron and other automation tools may use a smaller PATH than your interactive shell.
• Reinstalling MySQL before checking whether /usr/local/mysql/bin/mysql already works.

Summary

• 'mysql: command not found is usually a shell path problem, not a broken MySQL install.'
• Verify the client with its absolute path before changing anything else.
• Add MySQL's bin directory to the correct shell startup file and reload it.
• Use a symlink under /usr/local/bin if you need a more stable command location.
• Treat server connectivity as a separate check after the command itself resolves.