Unless you're using the cheapest SSDs on the consumer market, and with databases at 100GB+ you probably won't, this is not likely to be a problem for you.
You'd have to be doing a really large amount of writing to even come close to limiting the effective life of a modern (as in, manufactured in the last 12 months) SSD. The industry as a whole has managed to push cell endurance out enough, figured out how much spare area is needed to compensate for failed cells, and outright firmware optimizations that you should be able to get at least 3 years life with punishing performance even on consumer-grade hardware. For older SSDs this was true, but that is no longer the case; in most cases it's leftover mythology from an older era.
To be fair, MLC endurance is still a factor at high write loads. And by high we're talking the equivalent of multiple full-disk writes per day over the course of years. If you're in this performance class you're probably no longer in the 'consumer' market anyway.
Cell reprogramming performance hits
Or, what you said you need TRIM/Discard for. This is the well known 'defect' of MLC style SSDs. However, firmware tweaks over the years have mitigated most of the performance hit for writes to this style of SSD. SLC drives are still available and thanks to the tweaks to make MLC drives last longer the big reason to use SLC is no longer there, so they're pretty uncommon now. But if you are pushing enough tiny writes to disk that you'll be pushing the lifespan of an MLC, an SLC device begins to make sense.
If you allocate enough unused space on your DB drives most SSD firmware is smart enough to notice that certain blocks are unallocated and treat it like additional spare area. When background defrag processes kick off the spare area is reprovisioned. This will keep performance high. So the lack of block-level discard support in MySQL doesn't matter much.