I agree with Michael Green and have some additional points to add.
Is this a bad idea?
Yes. It might seem like it's the more convenient option for you right now, but a bit later you may come to regret this. Anyone else who has to query or report on this will use "many swear words" when they find it. The time you save now will be lost everytime you have to parse unpack and check these in the future.
Should I use 3 different fields?
Yes, or alternatively consider an XML (or JSON) field. I don't like XML, but at least it has some concept of structure, and can be queried with some confidence. It will also be easier to extend when you realise you need 4 parameters.. or don't want the 2nd any longer.
A clear advantage of using separate table fields is that you now rely upon data typing and can now relying upon the database to enforce rules such as whether a value can be NULL or not.
Does 3 text fields really affect database performance?
Not significantly, especially as it's the same amount of text so its taking up the same amount if space, or even less if you consider the delimiters. By using separate fields with indexes query performance is very likely to improve.
Relational databases have a lot of power and capability, which you will not be able to exploit if you cludge it all together. What might seem like a shortcut now will come back to haunt you later.