I need a matchmaking server, while the game will be peer to peer. I could either continually run a dedicated server at home with custom software, or I could just use my web-domain and insert players looking to play into a mysql table, and just have their game use http style requests to find people to play with. This was something I was doing when I made an Android game.

Any suggestions? Should be much cheaper to have it hosted on a web server that I already pay for and also save on electricity.

Suggestions for what? Yes, those are some options. Run it locally, trying to keep up, or run it from a server out in the world somewhere. Either way you need to write something to do that work for you.

Depending on your matchmaking needs it may not need a database; if all you care about is that anybody waiting gets hooked up with another player there isn't much data to hold, it can stay in memory with the server. If you have much more information, accounts and scores and leaderboards and such that can require a database. But the actual matchmaking process itself is usually a dynamic thing run from memory.

I know I can still write a c++ matchmaking server from scratch and decide to use a mysql database regardless, but my question was: does the alternative of just hosting a mysql database on my domain website (a shared webserver hosted on a random website I signed up for), and just having it run php scripts to add to the database and fetch from the database (such as server info or players), is there any reason that might be a bad idea? Either performance being that it is shared, or that it might be more flexible to write my own c++ server and run dedicated? Like I said, I had an android game that could run php scripts to manipulate a mysql DB all run on a shared webhosting server and it worked for testing a few players but I didn't know if this was a bad idea.

If matchmaking doesn't need to do NAT introduction/punch-through, then hosting on a web server seems fine.
You might want to use a more ephemeral store than MySQL, though, such as Redis or memcached.
For low volumes, it doesn't matter, but for high volumes, having to sweep the "current lookers" table for stale entries all the time ends up having a real cost.